271–280 of 339 posts
Most of the "bugs" caught here (including in TensorFlow and in my own project, Xarray) seems to actually be typos in the test suite. This is certainly a good catch (and yes, linters should check for this!), but seems a little oversold to me.
Literally the second item in the "Zen of Python" ( https://www.python.org/dev/peps/pep-0020/ ): Explicit is better than implicit. And yet, s = ["one", "two" "three"] will implicitly and silently do something, that is probably wrong most of the time.
Hmmm, it sounds like you're expecting "two" and "three" to be separate list elements because of some sort of implicit behavior due to being written in a list context. This is the opposite of what "Explicit is better than implicit" means. This is a list and you must explicitly place a comma when you want to start a new element in the list. Is there ever a time a new element follows a previous one and is NOT separated…
Yes:
[ "one, two", "three" ]
The high-level goals of python end up creating these little syntactic landmines that can get even experienced coders. My personal nomination for the worst one of these is that having a comma after a single value often (depending on the surrounding syntax) creates a tuple. It's easy to miss and creates maddening errors where nothing works how you expect. I've moved away from working in Python in general, but I think t…
The lack of a static type-system is IMO what makes these one-character mistakes very annoying. The compiler can't tell you something is wrong, so you're just left to figure out why things are broken, just to realize it was the smallest of typos.
I say "had a proper type system", but actually it turns out that it does have something like that: When I use python for anything else than a most tiny script now, I use "mypy"[1] which implements static typing according to some existing Python standard (whether that came about because of mypy or the other way around, I don't know).
It is so, so good to have mypy telling me where I messed up my code instead of receiving a cryptic, weird runtime error, or worse, no error and erratic runtime behavior. Because not knowing that a particular type is unexpected and wrong, values often get passed along and even manipulated until the resulting failure is not very indicative of the actual problem anymore.
Earlier quoted context omitted.
The lack of a static type-system is IMO what makes these one-character mistakes very annoying. The compiler can't tell you something is wrong, so you're just left to figure out why things are broken, just to realize it was the smallest of typos.
C lets me do this, and doesn't say much about it. char ch_arr[3][10] = { "uno", "dos" "tres" };
The high-level goals of python end up creating these little syntactic landmines that can get even experienced coders. My personal nomination for the worst one of these is that having a comma after a single value often (depending on the surrounding syntax) creates a tuple. It's easy to miss and creates maddening errors where nothing works how you expect. I've moved away from working in Python in general, but I think t…
In hindsight, singleton tuples are not common or useful enough to deserve their own syntax. If the way to create them was something like this:
t = tuple.single("hello")
Python was never supposed to be a language for anything more complex than basic scripting and prototyping. Use proper languages with static typing (and better speed) for anything serious. And no, JavaScript isn't a good language either.
As a comparison, in Ruby puts "a" "b" == "ab" # true and puts "a" "b" == "ab" prints "a" with "b" == "ab" evaluated to false and discarded. This could create bugs as with Python. However ["a" "b"] == ["ab"] is syntax error at the beginning of the second line. The parser expects a ] It would evaluate to true if it were on one line.
The implicit concat of string literals is the culprit here. It really should require "+".
Earlier quoted context omitted.
I still don't understand why it doesn't! So I still get bit from time to time.
If a person decides to add parentheses to some booleans or arithmetic, (4 + 5) * (8 + 2) (this and that) or (theother) These elements should not become 1-tuples after the interior contents are evaluated. I sometimes add parentheses even around single variables just for visual clarity. Also, this allows you to do dot-access on int / float literals, if you want to # doesn't work 4.to_bytes(8, 'little') # works (4).to_b…