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

[Ron Adam]

On 05/17/2013 06:41 AM, Steven D'Aprano wrote:
> On 17/05/13 19:32, Christian Tismer wrote:
>> On 16.05.13 20:20, Chris Angelico wrote:
>>> On Fri, May 17, 2013 at 4:14 AM, Bruce Leban
>>> <bruce at leapyear.org> wrote:
>
>>>> I'm not passionate about that detail if the rest of the proposal flies.
>>>
>>> Spin that off as a separate thread, I think the change to the
>>> backslash rules stands alone. I would support it; allowing a
>>> line-continuation backslash to be followed by a comment is a Good
>>> Thing imo.
>>>
>>
>> I don't think these matters should be discussed in separate threads.
>
> They clearly should be in different threads. Line continuation is
> orthogonal to string continuation. You can have string concatenation on a
> single line:
>
> s = "Label:\t" r"Data containing \ backslashes"

Can you think of, or find an example of two adjacent strings on the same 
line that can't be written as a single string?

     s = "Label:\t Data containing \ backslashes"

I'm curious about how much of a problem not having implicit string 
concatenations really is?


> And you can have line continuations not involving strings:
>
> result = math.sin(23*theta) + cos(17*theta) - \
>      sin(3*theta**2)*cos(5*theta**3)
>
>
> Since the two things under discussion are independent, they should be
> discussed in different threads.
>
>
>> - implicit string concatenation becomes deprecated
>
> -1
>
> Implicit string concatenation is useful, and used by many people without
> problems.

This is why they are trying to find an explicit alternative.


>> - the backslash will allow comments, as proposed by Bruce
>
> +0
>
> It's not really that important these days. If you want comments, use
> brackets to group a multi-line expression.
>
>
>> - continuation of a string on the next line will later enforce the
>> backslash.
>
> I don't understand what this sentence means.
>
>
>> So repeating Bruce's example, the following would be allowed:
>>
>> x = [  # THIS WOULD BE ALLOWED
>>      'abc'   \
>>      'def'   \   # not the python keyword
>>      'ghi'
>> ]
>
> The backslashes are redundant, since the square brackets already enable a
> multi-line expression.

But it is also a source of errors which appears to happen often enough, or 
is annoying enough, to be worth changing.

Guido's example was a situation where a comma was left out and two strings 
were joined inside a list without an error message.

If you accidentally put a comma in a multi line expression inside 
parentheses, it becomes a tuple without an error message.

 >>> ('abc'
... 'def',
... 'ghi')
('abcdef', 'ghi')


By removing implicit string concatenations, an error can be raised in some 
of these situations.  The fact that these errors are silent and may not be 
noticed until a programs actually used is an important part of this.

Or even worse, not noticed at all!



>> '\' would become kind of a line glue operator that becomes
>> needed to merge the strings.
>
> -1 since there are uses for concatenating strings on a single line.

Guido's suggestion is just to live with using a '+'.  His point was that 
any extra overhead wouldn't be that harmful as literal string 
concatenations tend to be in initiation parts of programs.

But the + has a lower precedence than %.  Which is inconvenient.



>> I don't think that parentheses are superior for that.
>> Parentheses are for expressions and they suggest expressions.
>> Avoiding parentheses where they don't group parts of expressions
>> is imo a good thing.

I agree with this.  Especially if the expression being grouped has 
parentheses inside it.


> I don't understand this objection, since the parentheses are being used to
> group an expression.
> And they are being used to group expressions.

It's also a matter of reducing errors.  I think it improves readability as 
well.  Which also reduces errors.



>> The reason why Python has grown the recommendation to use parentheses
>> comes more from the absence of a good alternative.
>
> Maybe so, but now that we have multi-line expressions inside brackets, the
> need for an alternative is much reduced.

If you use braces, you get a one item list as the result.

Parentheses are used to change an expressions order of evaluation as well.


Ron