[Python-ideas] Parenthesized Compound With Statement

[Ron Adam]

On 07/03/2013 12:34 PM, Guido van Rossum wrote:
> On Wed, Jul 3, 2013 at 9:56 AM, Ron Adam <ron3200 at gmail.com> wrote:
>>
>>
>> On 07/03/2013 10:01 AM, Barry Warsaw wrote:
>>>
>>> As for relaxing PEP 8, well, I'm not sure what more you'd want it to say.
>>> It
>>> currently reads:
>>>
>>>       The preferred way of wrapping long lines is by using Python's implied
>>>       line continuation inside parentheses, brackets and braces.  Long
>>> lines
>>>       can be broken over multiple lines by wrapping expressions in
>>>       parentheses. These should be used in preference to using a backslash
>>>       for line continuation.
>>>
>>> which seems about right to me.  It is preferred to use implied
>>> continuation
>>> over backslashes, but doesn't say "don't use backslashes".  They're not
>>> evil,
>>> just not preferred, so use them where appropriate and with good judgment.
>>
>>
>>
>> I think this can be improved on.  The second part should be a positive
>> statement expressing when backslashes should be used over an implied
>> continuation, rather than a blanket negative statement.
>>
>>      Use a backslash if parentheses cause the code to be less clear.
>>
>>
>>
>>
>> My own preference is:
>>
>> Use what obviously reads better.
>
> Too subjective.

And is why I added the clarification just below.

>> This can happen when continuing
>> expressions which contain tuples, or strings with backslashes.  Using what
>> is not in the expression can help make the intention clearer.


>> Use what takes less characters.  For an expression that span 2 lines, use a
>> single backslash. For longer expressions spanning 4 or more lines
>> parentheses are preferred.
>
> Wrong. For breaking expressions, it's almost always better to use
> parentheses, even if you have to add them, because they can always be
> added.

Is there any time a '\' can't be added?


> The backslashes remain preferred in cases where the natural break
> point is such that you cannot add parentheses syntactically. In Python
> 3 this is mainly assert and with (in Python 2 it included import).

In this case, it's preferred over extending the line over 80 chars.


> What I am trying to avoid here is that people break their lines at an
> unnatural place just so they can avoid the backslash. An examples of
> an unnatural break:

The difficult part of communicating concepts like these is knowing when to 
put in additional supporting details and when to leave them out.   I agree 
with the above and include it in the 'what reads better' category, but 
maybe it needs to be noted in PEP 8.

Fortunately improving documentation can be viewed a process, and we can 
make adjustments as it's needed.


>    assert some_long_expression_fitting_on_one_line(), "foo {} bar".format(
>        "argument that easily fits on a line")
>
> Here, the natural (highest-level) breakpoint is right after the comma,
> and the (bad) solution used in this example is to take the expression
>
>    "foo {} bar".format("argument that easily fits on a line")
>
> and break it after the parentheses. The resulting layout is a mess:
> the first line contains one-and-a-half item, the second line half an
> item. Note that when breaking expressions or argument lists you won't
> have to do this: if instead of assert we had a call, you would break
> at the comma:
 >
>    whatever(some_long_expression_fitting_on_one_line(),
>        "foo {} bar".format("argument that easily fits on a line"))
>
> (Leaving aside not the issue of how many spaces to use to indent the
> second line -- I am typing this in a variable-width font so I don't
> want to play ASCII-art and align the first " under the 's' of 'some',
> even though that's what Emacs would do and I usually let it.)
>
>> For continued lines inside of function calls, and container literals,
>> indenting the continued lines is enough in most cases.
>
> Again, don't break in the middle of an argument that would fit on a
> line by itself, even if you end up needing an extra line in total. I
> strongly prefer
>
>    foo(expr1,
>        expr2a + expr2b,
>        expr3)
>
> over
>
>    foo(expr1, expr2a +
>        expr2b, expr3)
>
> Similar if expr2 has its own parentheses.

I agree.


>> Sometimes adding a backslash within a container can make a continued line
>> between many single line items stand out better. (*)
>>
>>
>> (* There have been "silent" bugs where a comma was omitted in cases where
>> some lines are continued and some aren't.)
>
> I don't understand what you are referring to here, but I don't think
> we should invoke backslashes to solve the problem of significant
> trailing commas.

I'll see if I can find some real examples of this.

It's a case where there is a long list, and every once in a while there is 
a long line that is implicitly continued.  So an occasional missing comma 
is what is supposed to be there.  Which makes seeing an actual missing 
comma is harder to do.

When there is a long list with only a few continuations, I don't see how a 
few backslashes would be harmful, they would explicitly show those line are 
meant to be continued and are not missing a comma.

I don't think this comes up that often, so it probably doesn't need any 
special treatment.

Cheers,
     Ron