11–20 of 339 posts
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.
puts "a" "b" == "ab" # true
puts "a"
"b" == "ab"
["a"
"b"] == ["ab"]
I am a bit in shock. Accidental string concatenation. Python just lost a lot of reputation in my brain.
The removal of implicit string concatenation was proposed for Py3k[1], but was rejected. [1] https://www.python.org/dev/peps/pep-3126/
> This PEP is rejected. There wasn't enough support in favor, the feature to be removed isn't all that harmful, and there are some use cases that would become harder.
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…
Python has a few of these things, which is really sad.
I really like the idea of automated code review tools that point out unusual or suspicious solutions and code patterns. Kind of like an advanced linter that looks deeper into the code structure. With emerging AI tools like Github Copilot, it seems like the inevitable future. Programming is very pattern-oriented and even though these kinds of tools might not necessarily be able to point out architectural flaws in a co…
Even without static typing, argument length verification etc. can be done with a suitable compiler. In python we are left chasing 100% code coverage in unit tests as it's the only way to be certain that the code doesn't include a silly mistake.
(Python copies some bad ideas from C. Another one is having to import everything you use. It seems that since Python is written in C, its designer took it for granted that there will be something analogous to #include for using libraries, even standard ones that come with the language.)
Implicit string literal catenation is tempting to implement because it solves problems like:
printf("long %s string"
"nicely breaks up"
"with indentation and all",
arg, arg, ...)
There are other ways to solve it. In TXR Lisp, I allow string literals to go across multiple lines with a backslash newline sequence. All contiguous unescaped whitespace adjacent to the backslash is eaten:
This is the TXR Lisp interactive listener of TXR 273.
Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
TXR needs money, so even abnormal exits now go through the gift shop.
1> "abcd \
efg"
"abcdefg"
2> "abcd\ \
efg"
"abcd efg"
3> "abcd \
\ efg"
"abcd efg"
4> "abcd \ \
efg"
"abcd efg"
5> "abcd \ \
\ efg"
"abcd efg"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…
Along those lines. I wonder how many of these come from ad-hoc file path handling instead of using pathlib.
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…