[Python-ideas] allow line break at operators

Yingjie Lan lanyjie at yahoo.com
Sat Sep 3 06:33:48 EDT 2011

Ambiguity: yes, when the last line of a suite is a continued line, it would require double dedentations to end the line and the suite. I noticed a similar case in current Python language as well:

if condition:
for i in range(5):
else: #double dedentations
for body in space:
#double dedentations again
log('triangulation done')

If lines can be continued by indentation, similar situation would rise:

if condition:
result = [sin(i) for i in range(5)]
+ [cos(i) for i in range(5)]

result = [cos(i) for i in range(5)]
+ [sin(i) for i in range(5)]

log('triangulation done')

Generating text example: right, this is a case that can't be handled by standard indentation, unless we only consider full dedentation (dedentation to the exact level of the initial indentation) as the signal of ending the line. Whether to accommodate for such a case might be an issue of debate, but at least we can have such 'freedom' :)

>From: Stephen J. Turnbull <stephen at xemacs.org>
>To: Yingjie Lan <lanyjie at yahoo.com>
>Cc: Gabriel AHTUNE <gahtune at gmail.com>; Matt Joiner <anacrolix at gmail.com>; python-ideas <python-ideas at python.org>
>Sent: Saturday, September 3, 2011 5:29 PM
>Subject: Re: [Python-ideas] allow line break at operators
>Yingjie Lan writes:
>> Python uses indentation for blocks, and by the same mechanism, line
>> breaking can be accommodated without requiring parenthesis or
>> ending backslashes.
>Possibly, but now you have a problem that a dedent has ambiguous
>meaning.  It might mean that you're ending a suite, or it might mean
>you're ending a continued expression.  This probably can be
>disambiguated, but I don't know how easy that will be to do perfectly,
>including in reporting ill-formed programs.
>> Most people seems to like an indentation on the continuing lines,
>Most of the time, yes, but sometimes not.  For example, in generating
>text, it's often useful to dedent substantially so you can have a
>nearly normal length line in the literal strings being concatenated.
>Or you might have a pattern like this:
>    x = long_named_variable_a
>            - long_named_variable_a_base
>        + long_named_variable_b
>            - long_named_variable_b_base
>which your parser would raise an error on, I presume.  That's not
>freedom!<wink />
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20110903/a13255b2/attachment.html>

More information about the Python-list mailing list