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

Christian Tismer tismer at stackless.com
Thu May 16 18:57:29 CEST 2013


On 16.05.13 18:23, MRAB wrote:
> On 16/05/2013 16:57, Andrew Barnert wrote:
>> On May 16, 2013, at 8:00, MRAB <python at mrabarnett.plus.com> wrote:
>>
>>> On 16/05/2013 15:44, Chris Angelico wrote:
>>>> On Fri, May 17, 2013 at 12:40 AM, MRAB
>>>> <python at mrabarnett.plus.com> wrote:
>>>>> On 16/05/2013 08:08, Serhiy Storchaka wrote:
>>>>>> As was said before the '+' operator has less priority than
>>>>>> the '%' operator and an attribute access, i.e. it requires
>>>>>> parenthesis in some cases. However parenthesis introduce a
>>>>>> noise and can cause other types of errors.
>>>>> I wonder whether we could use ".". Or would that be too
>>>>> confusing?
>>
>>>> And I apologized for borrowing an idea from bash. Taking an idea
>>>> from PHP?!?
>>> It has high precendence as far as the parser is concerned.
>>>
>>> I know that Perl uses it. I haven't looked at PHP (I hear bad
>>> things about it! :-)).
>>>
>>>> Seriously, I don't think another operator is needed. If it's not
>>>> going to be the implicit concatenation by abuttal, + or \ will
>>>> carry the matter. But I share the opinion of several here:
>>>> implicit concatenation is not as bad as the alternatives.
>>> It wouldn't be an operator as such
>>
>> Of course in php, perl, and every other language that uses dot for
>> string concatenation, it _is_ an operator, so this will end up
>> confusing the very people who initially find it comforting.
>>
>> And this means the parser has to figure out whether you mean dot for
>> attribute access or dot for concatenation. That's not exactly a
>> _hard_ problem, but it's not _trivial_.
>>
>> And then there's the fact that the "precedence" is different
>> depending on which meaning the dot gets. Remember that what you're
>> trying to solve is the problem that member-dot and % both have higher
>> precedence than +.
>>
> I thought the problem we were trying to solve was that "+" has a lower
> precedence than "%" and attribute/method access, so implicit
> concatenation that's followed by "%" or ".format" can't be replaced by
> "+" without adding extra parentheses.

I think the "." is a nice idea at first sight, but might become confusing
in the end because what we actually need is a simple to use notation
for the scanner/parser that denotes a continuation line, and _not_ an
operator.

Now, what about this?

     long_line = "the beginning and the"&          # comments are ok
                       " continuation of a string"

The "&" is not a valid operator on strings and looks pretty much like
gluing parts together. It is better than the "\" that just escapes the 
newline
and cannot take comments.
I would even enforce that the ampersand be on the same line.

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
Software Consulting          :     Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121     :    *Starship* http://starship.python.net/
14482 Potsdam                :     PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
       whom do you want to sponsor today?   http://www.stackless.com/



More information about the Python-ideas mailing list