[Python-ideas] Implicit string literal concatenation considered harmful?

[Guido van Rossum]

On Fri, May 10, 2013 at 4:27 PM, Eli Bendersky <eliben at gmail.com> wrote:
>
> On Fri, May 10, 2013 at 11:48 AM, Guido van Rossum <guido at python.org> 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?
>
>
> I would also be happy to see this error-prone syntax go (was bitten by it a
> number of times in the past), but I have a practical question here:
>
> Realistically, what does "start deprecating" and "eventually remove" means
> here? This is a significant backwards-compatibility breaking change that
> will *definitely* break existing code. So would it be removed just in
> "Python 4"? Or are you talking about an actual 3.x release like "deprecate
> in 3.4 and remove in 3.5" ?

It's probably common enough that we'd have to do a silent deprecation
in 3.4, a nosy deprecation in 3.5, and then delete it in 3.6, or so.
Or maybe even more conservative.

Plus we should work on a conversion tool that adds + and () as needed,
*and* tell authors of popular lint tools to add rules for this.

The hacky proposals for making it a syntax warning "sometimes" don't
feel right to me.

I do realize that this will break a lot of code, and that's the only
reason why we may end up punting on this, possibly until Python 4, or
forever. But I don't think the feature is defensible from a language
usability POV. It's just about backward compatibility at this point.

-- 
--Guido van Rossum (python.org/~guido)