On 14/03/2018 17:57, Chris Angelico wrote:
On Thu, Mar 15, 2018 at 12:40 AM, Søren Pilgård <fiskoma...@gmail.com> wrote:
Of course you can always make error, even in a single letter.
But I think there is a big difference between mixing up +-/* and **
where the operator is in "focus" and the implicit concatenation where
there is no operator.
A common problem is that you have something like
foo(["a",
"b",
"c"
]).bar()
but then you remember that there also needs to be a "d" so you just add
foo(["a",
"b",
"c"
"d"
]).bar()
Causing an error, not with the "d" expression you are working on but
due to what you thought was the previous expression but python turns
it into one.
The , is seen as a delimiter by the programmer not as part of the
operation (or the lack of the ,).
You're creating a list. Put a comma at the end of every line; problem
solved. Your edit would be from this:
foo(["a",
"b",
"c",
]).bar()
to this:
foo(["a",
"b",
"c",
"d",
]).bar()
and there is no bug. In fact, EVERY time you lay out a list display
vertically (or dict or set or any equivalent), ALWAYS put commas. That
way, you can reorder the lines freely (you don't special-case the last
one), you can append a line without changing the previous one (no
noise in the diff), etc, etc, etc.
My thoughts exactly. I make it a personal rule to ALWAYS add a comma to
every line, including the last one, in this kind of list (/dict/set
etc.). *Python allows it - take advantage of it!* (A perhaps
minor-seeming feature of the language which actually is a big benefit if
you use it.) Preferably with all the commas vertically aligned to
highlight the structure (I'm a great believer BTW in using vertical
alignment, even if it means violating Python near-taboos such as more
that one statement per line). Also I would automatically put the first
string (as well as the last) on a line by itself:
foo([
"short string" ,
"extremely looooooooooooong string" ,
"some other string" ,
])
Then as Chris says (sorry to keep banging the drum), the lines can
trivially be reordered, and adding more lines never causes a problem as
long as I stick to the rule. Which I do automatically because I think
my code looks prettier that way.
From a purist angle, implicit string concatenation is somewhat
inelegant (where else in Python can you have two adjacent operands not
separated by an operator/comma/whatever? We don't use reverse Polish
notation). And I could live without it. But I have found it useful
from time to time: constructing SQL queries or error messages or other
long strings that I needed for some reason, where triple quotes would be
more awkward (and I find line continuation backslashes ugly,
*especially* in mid-string). I guess my attitude is: "If you want to
read my Python code, 90%+ of the time it will be *obvious* that these
strings are *meant* to be concatenated. But if it isn't, then you need
to learn some Python basics first (Sorry!).".
I have never as far as I can remember had a bug caused by string
concatenation. However, it is possible that I am guilty of selective
memory.
+1, though, for linters to point out possible errors from possible
accidental omission of a comma (if they don't already). It never hurts
to have our code checked.
Best wishes
Rob Cliffe
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
