[Python-ideas] Implicit string literal concatenation considered harmful (options)

[Steven D'Aprano]

On 19/05/13 04:16, Ron Adam wrote:

> If implicit string concatenation is removed, it would be nice if there was an explicit replacement for it.  There is a strong consensus for doing it,

I don't think there is. From what I have seen, there have been nearly as many people objecting to the proposed removal as there have been people supporting it, it is only that some of the people supporting the removal are more vocal, proposing alternative after alternative, none of which are particularly nice. Single dot, ellipsis, yet another string prefix c'', forced backslashes, ampersand... Have I missed any?


> but there isn't strong consensus on how to do it.

> About line continuations:
>
> Line continuations are a related issue to string concatenations because they are used together fairly often.

They might be related, but they are orthogonal. We could change one, or the other, or both, or neither. There are virtues to changing the behaviour of \ line concatenation independent of any changes made to strings.


> The line continuation behaviour is a bit quarky,

Do you mean "quirky"? Quarky would mean "like quark(s)", which could refer to something being like a type of German cream cheese, or possibly like fundamental subatomic particles that make up protons and neutrons.


> There are a number of options that have been discussed but those haven't really been clearly spelled out so the discussion has been kind of out of focus.   This seems like an overly detailed list, but the discussion has touched on pretty much all of these things.  I think the goal should be to find the most cohesive combination for Python 4 and/or just go with B alone.
>
>
> A.  Do nothing.
>
> B.  Remove implicit concatenation.
>
>    (We could stop here, anything after this can be done later.)


We can't just "remove implicit concatenation", because that will break code which is currently working perfectly. And probably it will break more working code than it will fix unnoticed broken code.

So removal requires a deprecation schedule: deprecate for at least one release. The conservative approach is:

* mark as deprecated in the docs in 3.4;

* raise a deprecated warning in 3.5;

* remove in 3.6.

or even later. Any removal of functionality leads to code churn: people will be forced to change code that works now because it will stop working in the future. That's a serious cost even when there are clear and obvious benefits to the removal.



-- 
Steven