[Python-ideas] allow line break at operators

[MRAB]

On 04/09/2011 00:22, Yingjie Lan wrote:
>>  Every language with blocks needs some mechanism to indicate the
> beginning and ending of blocks and of statements within blocks. If
> visible fences ('begin/end' or '{}') and statement terminators (';') are
> used, then '\n' can be treated as merely a space, as it is in C, for
> instance.
>>  and it uses unescaped '\n' (with two escapement options) to terminate
> statements. This is fundamental to Python's design and goes along with
> significant indents.
>
> Agreed. Currently indentation in Python starts a new block, but if you
> view it from the perspective of line breaking, it also functions as if
> the line is continued. The line of code below
>
> if condition: do_a(); do_b()
>
> can be written as:
>
> if condition: #line breaks
> do_a(); # ';' is optional here
> do_b() # continue
>
> That indentation can be also employed for line breaking is quite evident
> to me. During the open email correspondence with Stephen, it seems to be
> a tenable point.
>
>  > There would then be three ways to escape newline, with one doing
> double duty. And for what? Merely to avoid using either of the two
> methods already available.
>
> I believe the other two ways are not as good as this new way. As the
> proposal is fully backward compatible, people may choose whatever way
> they prefer.
>
I think that the rules would be:

If a line ends with a colon and the next line is indented, then it's
the start of a block, and the following lines which belong to that
block have the same indent.

If a line doesn't end with a colon but the next line is indented, then
it's the start of a continuation, and the following lines which belong
to that continuation have the same indent.

In both cases there could be blocks nested in blocks and possibly
continuations nested in continuations, as well as blocks nested in
continuations and continuations nested in blocks.

I'm not sure what the effect would be if you had mis-indented lines.
For example, if a line was accidentally indented after a comment, then
it would be treated as part of the comment. It's in cases like those
that syntax colouring would be helpful. It would be a good idea to use
an editor which could indicate in some way when a line is a
continuation.

>     ------------------------------------------------------------------------
>     *From:* Terry Reedy <tjreedy at udel.edu>
>     *To:* python-list at python.org
>     *Cc:* python-ideas at python.org
>     *Sent:* Sunday, September 4, 2011 3:01 AM
>     *Subject:* Re: [Python-ideas] allow line break at operators
>
>     On 9/3/2011 3:51 AM, Yingjie Lan wrote:
>      > I agree that long lines of code are not very common in many projects,
>      > though it might be the case with some heavily involved in math.
>     For some
>      > reason, when the feature of free line breaking came about in computer
>      > languages, it is welcomed and generally well accepted.
>
>     Every language with blocks needs some mechanism to indicate the
>     beginning and ending of blocks and of statements within blocks. If
>     visible fences ('begin/end' or '{}') and statement terminators (';')
>     are used, then '\n' can be treated as merely a space, as it is in C,
>     for instance.
>
>      > Python uses indentation for blocks,
>
>     and it uses unescaped '\n' (with two escapement options) to
>     terminate statements. This is fundamental to Python's design and
>     goes along with significant indents.
>
>      > and by the same mechanism, line breaking can be
>      > accommodated without requiring parenthesis or ending backslashes.
>
>     You need proof for your claim that indentation can be used for both
>     jobs in the form of a grammar that works with Python's parser. I am
>     dubious that you can do that with an indents *after* the newline.
>
>     Even if you could, it would be confusing for human readers. There
>     would then be three ways to escape newline, with one doing double
>     duty. And for what? Merely to avoid using either of the two methods
>     already available.
>