On 11/05/13 04:48, Guido van Rossum wrote:
I just spent a few minutes staring at a bug caused by a missing comma -- I got a mysterious argument count error because instead of foo('a', 'b') I had written foo('a' 'b').
This is a fairly common mistake, and IIRC at Google we even had a lint rule against this (there was also a Python dialect used for some specific purpose where this was explicitly forbidden).
Now, with modern compiler technology, we can (and in fact do) evaluate compile-time string literal concatenation with the '+' operator, so there's really no reason to support 'a' 'b' any more. (The reason was always rather flimsy; I copied it from C but the reason why it's needed there doesn't really apply to Python, as it is mostly useful inside macros.)
Would it be reasonable to start deprecating this and eventually remove it from the language?
Not unless you guarantee that compile-time folding of string literals with '+' will be a language feature rather than an optional optimization. I frequently use implicit string concatenation for long strings, or to keep within the 80 character line limit. I teach people to prefer it over '+' because: - constant folding is an implementation detail that is not guaranteed, and not all versions of Python support; - even when provided, constant folding is an optimization which might not be present in the future[1]; - implicit string concatenation is a language feature, so every Python must support it; - and is nicer than the current alternatives involving backslashes or triple-quoted strings. The problems caused by implicit string concatenation are uncommon and mild. Having two string literals immediately next to each other is uncommon; forgetting the comma makes it rarer. So I think the benefit of implicit string concatenation far outweighs the occasional problem. [1] I recall you (GvR) publicly complaining about CPython optimizations and suggesting that they are more effort than they are worth and should be dropped. I don't recall whether you explicitly included constant folding in that. -- Steven