21–30 of 339 posts
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.
Seems expected, as linters can't be sure when it's not intentional. Like this request to pylint: https://github.com/PyCQA/pylint/issues/1589 Is there usually enough context for a linter to make an educated guess?
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.
This is not what implicit is about.
This seems like not a big deal. It’s a common mistake and is in 5% of repos but it’s not causing major damage. And there’s no evaluation of importance as to whether these instances are in test files or non-critical code. Packages are big and can have hundreds or thousands of files. It could be that if these mattered, they would have been detected and fixed. A good example for unit tests and perhaps checking to see if…
5% of 'released' software is quite a lot, more importantly it's a class of errors that definitely should not exist. This is a 'bug' in the language effectively there just isn't any real upside. Python has a few of these things, which is really sad.
I am a bit in shock. Accidental string concatenation. Python just lost a lot of reputation in my brain.
Misspelling a variable on the lhs of an assignment just causes a new variable to be created with the new name. That's a lot worse in my book.
Yes, you'll certainly find somebody who doesn't know what 'not statically typed' means, but ... And yes, there are also C(++) users, that expect strings to be concatenated like that.
tl;dr: Python concatenates space separated strings, so ['foo' 'bar'] becomes ['foobar'], leading to silent bugs due to typos. I've been bitten by this one at work, and can't help but think it is an insane behaviour, given that ['foo' + 'bar'] explicitly concatenates the strings, and ['foo', 'bar'] is the much more common desired result. edit: This also applies to un-separated strings, so ['foo''bar'] also becomes ['f…
I assume it's based on the C behavior, where it can be handy with macros I don't think it fits well in python
This seems like not a big deal. It’s a common mistake and is in 5% of repos but it’s not causing major damage. And there’s no evaluation of importance as to whether these instances are in test files or non-critical code. Packages are big and can have hundreds or thousands of files. It could be that if these mattered, they would have been detected and fixed. A good example for unit tests and perhaps checking to see if…
5% of 'released' software is quite a lot, more importantly it's a class of errors that definitely should not exist. This is a 'bug' in the language effectively there just isn't any real upside. Python has a few of these things, which is really sad.
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.
# list
list = "a","b",
# function
def foobar
end
=> ["a", "b", :foobar]
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.