<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 14/03/2018 17:57, Chris Angelico
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAPTjJmpLhramXpa0nQx5LFR1JGgD8zatx2N3=HRnbHpsuetekA@mail.gmail.com">
<pre wrap="">On Thu, Mar 15, 2018 at 12:40 AM, Søren Pilgård <a class="moz-txt-link-rfc2396E" href="mailto:fiskomaten@gmail.com"><fiskomaten@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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 ,).
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
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.). <b>Python allows it - take advantage of it!</b>
(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:<br>
foo([<br>
"short string"
,<br>
"extremely looooooooooooong string" ,<br>
"some other string" ,<br>
])<br>
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.<br>
<br>
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!).".<br>
<br>
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.<br>
<br>
+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.<br>
<br>
Best wishes<br>
Rob Cliffe<br>
</body>
</html>