[Python-ideas] Parenthesized Compound With Statement

[Guido van Rossum]

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.

> 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.

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).

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:

  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.

> 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.

-- 
--Guido van Rossum (python.org/~guido)