[Python-Dev] [Python-3000] Implicit String Concatenation and Octal Literals Was: PEP 30XZ: Simplified Parsing

[Talin]

Raymond Hettinger wrote:
>>    Raymond> I find that style hard to maintain.  What is the advantage over
>>    Raymond> multi-line strings?
>>
>>    Raymond>  rows = self.executesql('''
>>    Raymond>     select cities.city, state, country
>>    Raymond>     from cities, venues, events, addresses
>>    Raymond>     where cities.city like %s
>>    Raymond>           and events.active = 1
>>    Raymond>           and venues.address = addresses.id
>>    Raymond>           and addresses.city = cities.id
>>    Raymond>           and events.venue = venues.id
>>    Raymond>     ''', 
>>    Raymond>     (city,))
> 
> [Skip]
>> Maybe it's just a quirk of how python-mode in Emacs treats multiline strings
>> that caused me to start doing things this way (I've been doing my embedded
>> SQL statements this way for several years now), but when I hit LF in an open
>> multiline string a newline is inserted and the cursor is lined up under the
>> "r" of "rows", not under the opening quote of the multiline string, and not
>> where you chose to indent your example.  When I use individual strings the
>> parameters line up where I want them to (the way I lined things up in my
>> example).  At any rate, it's what I'm used to now.
> 
> 
> I completely understand.  Almost any simplification or feature elimination
> proposal is going to bump-up against, "what we're used to now".
> Py3k may be our last chance to simplify the language.  We have so many
> special little rules that even advanced users can't keep them
> all in their head.  Certainly, every feature has someone who uses it.
> But, there is some value to reducing the number of rules, especially
> if those rules are non-essential (i.e. implicit string concatenation has
> simple, clear alternatives with multi-line strings or with the plus-operator).
> 
> Another way to look at it is to ask whether we would consider 
> adding implicit string concatenation if we didn't already have it.
> I think there would be a chorus of emails against it -- arguing
> against language bloat and noting that we already have triple-quoted
> strings, raw-strings, a verbose flag for regexs, backslashes inside multiline
> strings, the explicit plus-operator, and multi-line expressions delimited
> by parentheses or brackets.  Collectively, that is A LOT of ways to do it.
> 
> I'm asking this group to give up a minor habit so that we can achieve
> at least a few simplifications on the way to Py3.0 -- basically, our last chance.
> 
> Similar thoughts apply to the octal literal PEP.  I'm -1 on introducing
> yet another way to write the literal (and a non-standard one at that).
> My proposal was simply to eliminate it.  The use cases are few and
> far between (translating C headers and setting unix file permissions).
> In either case, writing int('0777', 8) suffices.  In the latter case, we've
> already provided clear symbolic alternatives.  This simplification of the
> language would be a freebie (impacting very little code, simplifying the
> lexer, eliminating a special rule, and eliminating a source of confusion
> for the young amoung us who do not know about such things).

My counter argument is that these simplifications aren't simplifying 
much - that is, the removals don't cascade and cause other 
simplifications. The grammar file, for example, won't look dramatically 
different if these changes are made. The simplification argument seems 
weak to me because the change in overall language complexity is very 
small, whereas the inconvenience caused, while not huge, is at least 
significant.

That being said, line continuation is the only one I really care about. 
And I would happily give up backslashes in exchange for a more sane 
method of continuing lines. Either way avoids "spurious" grouping 
operators which IMHO don't make for easier-to-read code.

-- Talin