|| ||Guido van Rossum <guido-+ZN9ApsXKcEdnm+yROfE0A-AT-public.gmane.org> |
|| ||Eli Bendersky <eliben-Re5JQEeQqe8AvxtiuMwx3w-AT-public.gmane.org> |
|| ||Re: Implicit string literal concatenation considered
|| ||Fri, 10 May 2013 16:41:34 -0700|
|| ||Python-Ideas <python-ideas-+ZN9ApsXKcEdnm+yROfE0A-AT-public.gmane.org>|
|| ||Article, Thread
On Fri, May 10, 2013 at 4:27 PM, Eli Bendersky <eliben-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> On Fri, May 10, 2013 at 11:48 AM, Guido van Rossum
>> 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)
to post comments)