Home Original page

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

Stefan Drees stefan at drees.name
Thu May 16 19:27:06 CEST 2013 
On 16.05.13 18:57, Christian Tismer wrote:
> 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.

'a bitwise or :-?'&
' why not ...'

in php the dot (.) is so abundantly used for staying within the line 
width limits, I often also insert it instead of a plus (+) when 
switching to python and the other way around.

All the best,

Stefan
More information about the Python-ideas mailing list