Mailman 3 Parenthesized Compound With Statement - Python-ideas

Parenthesized Compound With Statement

Matthew Lefavor

2 Jul 2013 2 Jul '13

10:37 p.m.

As you all know, Python supports a compound "with" statement to avoid the necessity of nesting these statements. Unfortunately, I find that using this feature often leads to exceeding the 79-character recommendation set forward by PEP 8. # The following is over 79 characters with open("/long/path/to/file1") as file1, open("/long/path/to/file2") as file2: pass This can be avoided by using the line continuation character, like so: with open("/long/path/to/file1") as file1, \ open("/long/path/to/file2") as file2: pass But PEP-8 prefers using implicit continuation with parentheses over line continuation. PEP 328 states that using the line continuation character is "unpalatable", which was the justification for allowing multi-line imports using parentheses: from package.subpackage import (UsefulClass1, UsefulClass2, ModuleVariable1, ModuleVariable2) Is there a reason we cannot do the same thing with compound with statements? Has this been suggested before? If so, why was it rejected? with (open("/long/path/to/file1") as file1, open("/long/path/to/file2") as file2): pass I would be happy to write the PEP for this and get plugged in to the Python development process if this is an idea worth pursuing. ML

Attachments:

attachment.htm (text/html — 2.3 KB)

Show replies by date

Guido van Rossum

3 Jul 3 Jul

3:04 a.m.

It would be easier to update PEP 8 to be less dogmatic about backslashes. Where parentheses work equally well, I prefer them. But for this and similar cases (asserts come to mind) I don't see why you can't use a backslash. I would certainly prefer that over a syntax change. On Tue, Jul 2, 2013 at 3:37 PM, Matthew Lefavor wrote:

...

As you all know, Python supports a compound "with" statement to avoid the necessity of nesting these statements.

Unfortunately, I find that using this feature often leads to exceeding the 79-character recommendation set forward by PEP 8.

# The following is over 79 characters with open("/long/path/to/file1") as file1, open("/long/path/to/file2") as file2: pass

This can be avoided by using the line continuation character, like so:

with open("/long/path/to/file1") as file1, \ open("/long/path/to/file2") as file2: pass

But PEP-8 prefers using implicit continuation with parentheses over line continuation. PEP 328 states that using the line continuation character is "unpalatable", which was the justification for allowing multi-line imports using parentheses:

from package.subpackage import (UsefulClass1, UsefulClass2, ModuleVariable1, ModuleVariable2)

Is there a reason we cannot do the same thing with compound with statements? Has this been suggested before? If so, why was it rejected?

with (open("/long/path/to/file1") as file1, open("/long/path/to/file2") as file2): pass

I would be happy to write the PEP for this and get plugged in to the Python development process if this is an idea worth pursuing.

ML

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

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

Andrew Barnert

4:16 a.m.

First, you can always do this: with open("/long/path/to/file1") as file1, open( "/long/path/to/file2") as file2: Not exactly beautiful, but perfectly legal and PEP-8-compliant. Or, of course: with open("/long/path/to/file1") as file1: with open("/long/path/to/file2") as file2: But the best solution is probably: path1 = "/long/path/to/file1" path2 = "/long/path/to/file2" with open(path1) as file1, open(path2) as file2: Meanwhile, PEP 8 doesn't say never to use backslashes no matter what. While it says parens "should be used in preference to using a backslash for line continuation", it also says, "But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment." In particular, it specifically says that "When applying the rule would make the code less readable, even for someone who is used to reading code that follows the rules", you should break it. So you've got four options in today's language. Is it worth changing the syntax to add a fifth? On Tue, Jul 2, 2013 at 3:37 PM, Matthew Lefavor wrote:

...

...
As you all know, Python supports a compound "with" statement to avoid the necessity of nesting these statements.

Unfortunately, I find that using this feature often leads to exceeding the 79-character recommendation set forward by PEP 8.

# The following is over 79 characters with open("/long/path/to/file1") as file1, open("/long/path/to/file2") as file2: pass

This can be avoided by using the line continuation character, like so:

with open("/long/path/to/file1") as file1, \ open("/long/path/to/file2") as file2: pass

But PEP-8 prefers using implicit continuation with parentheses over line continuation. PEP 328 states that using the line continuation character is "unpalatable", which was the justification for allowing multi-line imports using parentheses:

from package.subpackage import (UsefulClass1, UsefulClass2, ModuleVariable1, ModuleVariable2)

Is there a reason we cannot do the same thing with compound with statements? Has this been suggested before? If so, why was it rejected?

with (open("/long/path/to/file1") as file1, open("/long/path/to/file2") as file2): pass

I would be happy to write the PEP for this and get plugged in to the Python development process if this is an idea worth pursuing.

ML

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

Guido van Rossum

4:50 a.m.

Even though you are responding to my message, you omit what I wrote, and only weakly support it. So let me repeat: the backslash is the best solution and te PEP should be amended to prefer it *in this case*. On Tuesday, July 2, 2013, Andrew Barnert wrote:

...

First, you can always do this:

with open("/long/path/to/file1") as file1, open( "/long/path/to/file2") as file2:

Not exactly beautiful, but perfectly legal and PEP-8-compliant.

Or, of course:

with open("/long/path/to/file1") as file1: with open("/long/path/to/file2") as file2:

But the best solution is probably:

path1 = "/long/path/to/file1" path2 = "/long/path/to/file2" with open(path1) as file1, open(path2) as file2:

Meanwhile, PEP 8 doesn't say never to use backslashes no matter what. While it says parens "should be used in preference to using a backslash for line continuation", it also says, "But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment." In particular, it specifically says that "When applying the rule would make the code less readable, even for someone who is used to reading code that follows the rules", you should break it.

So you've got four options in today's language. Is it worth changing the syntax to add a fifth?

...
...
As you all know, Python supports a compound "with" statement to avoid

...
...
necessity of nesting these statements.

Unfortunately, I find that using this feature often leads to exceeding

On Tue, Jul 2, 2013 at 3:37 PM, Matthew Lefavor javascript:;> wrote: the the

...
...
79-character recommendation set forward by PEP 8.

# The following is over 79 characters with open("/long/path/to/file1") as file1, open("/long/path/to/file2") as file2: pass

This can be avoided by using the line continuation character, like so:

with open("/long/path/to/file1") as file1, \ open("/long/path/to/file2") as file2: pass

But PEP-8 prefers using implicit continuation with parentheses over line continuation. PEP 328 states that using the line continuation character is "unpalatable", which was the justification for allowing multi-line imports using parentheses:

from package.subpackage import (UsefulClass1, UsefulClass2, ModuleVariable1, ModuleVariable2)

Is there a reason we cannot do the same thing with compound with statements? Has this been suggested before? If so, why was it rejected?

with (open("/long/path/to/file1") as file1, open("/long/path/to/file2") as file2): pass

I would be happy to write the PEP for this and get plugged in to the Python development process if this is an idea worth pursuing.

ML

_______________________________________________ Python-ideas mailing list Python-ideas@python.org javascript:; http://mail.python.org/mailman/listinfo/python-ideas

-- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-ideas mailing list Python-ideas@python.org javascript:; http://mail.python.org/mailman/listinfo/python-ideas

-- --Guido van Rossum (on iPad)

Matthew Lefavor

5:29 a.m.

Works for me; I'll rescind my suggestion. The following is not intended as an objection, but rather as an opportunity for me to be educated about Python design decisions: Why were parenthetical import statements added? Is it simply because import statements are more common? On Wed, Jul 3, 2013 at 12:50 AM, Guido van Rossum wrote:

...

Even though you are responding to my message, you omit what I wrote, and only weakly support it. So let me repeat: the backslash is the best solution and te PEP should be amended to prefer it *in this case*.

On Tuesday, July 2, 2013, Andrew Barnert wrote:

...
First, you can always do this:

with open("/long/path/to/file1") as file1, open( "/long/path/to/file2") as file2:

Not exactly beautiful, but perfectly legal and PEP-8-compliant.

Or, of course:

with open("/long/path/to/file1") as file1: with open("/long/path/to/file2") as file2:

But the best solution is probably:

path1 = "/long/path/to/file1" path2 = "/long/path/to/file2" with open(path1) as file1, open(path2) as file2:

Meanwhile, PEP 8 doesn't say never to use backslashes no matter what. While it says parens "should be used in preference to using a backslash for line continuation", it also says, "But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment." In particular, it specifically says that "When applying the rule would make the code less readable, even for someone who is used to reading code that follows the rules", you should break it.

So you've got four options in today's language. Is it worth changing the syntax to add a fifth?

...
...
As you all know, Python supports a compound "with" statement to avoid

...
...
necessity of nesting these statements.

Unfortunately, I find that using this feature often leads to exceeding

...
...
79-character recommendation set forward by PEP 8.

# The following is over 79 characters with open("/long/path/to/file1") as file1, open("/long/path/to/file2") as file2: pass

This can be avoided by using the line continuation character, like so:

with open("/long/path/to/file1") as file1, \ open("/long/path/to/file2") as file2: pass

But PEP-8 prefers using implicit continuation with parentheses over

On Tue, Jul 2, 2013 at 3:37 PM, Matthew Lefavor wrote: the the line

...
...
continuation. PEP 328 states that using the line continuation character is "unpalatable", which was the justification for allowing multi-line imports using parentheses:

from package.subpackage import (UsefulClass1, UsefulClass2, ModuleVariable1, ModuleVariable2)

Is there a reason we cannot do the same thing with compound with statements? Has this been suggested before? If so, why was it rejected?

with (open("/long/path/to/file1") as file1, open("/long/path/to/file2") as file2): pass

I would be happy to write the PEP for this and get plugged in to the Python development process if this is an idea worth pursuing.

ML

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- --Guido van Rossum (on iPad)

Nick Coghlan

8:19 a.m.

On 3 July 2013 15:29, Matthew Lefavor wrote:

...

Works for me; I'll rescind my suggestion.

The following is not intended as an objection, but rather as an opportunity for me to be educated about Python design decisions: Why were parenthetical import statements added? Is it simply because import statements are more common?

Different times, and no syntactical ambiguity. with statements and asserts are different, as they already support parens (they just mean something different, and even though that meaning isn't useful, it's still valid syntax). For with statements, long ones can either be broken up with backslashes, or (in 3.3+) modified to use contextlib.ExitStack. Assert statements and escaping the first newline when dedenting an indented multi-line string literal are the other two main use cases where the escaped newline is the preferred (or only) option. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

João Bernardo

12:55 p.m.

2013/7/3 Guido van Rossum

...

It would be easier to update PEP 8 to be less dogmatic about backslashes.

+1 I found myself using backslashes a lot more than parentesis for such things. I would like the change on PEP8. João Bernardo

Barry Warsaw

3:01 p.m.

On Jul 02, 2013, at 06:37 PM, Matthew Lefavor wrote:

...

As you all know, Python supports a compound "with" statement to avoid the necessity of nesting these statements.

Unfortunately, I find that using this feature often leads to exceeding the 79-character recommendation set forward by PEP 8.

Yeah, I noticed and brought this up a while ago. I thought I filed a bug but can't find it. It would have been closed Won't Fix anyway. As others have pointed out, you can usually rewrite such long with-statements to conform to the PEP 8 line lengths by e.g. saving the paths in a shorter named local variable), using Python 3.3's ExitStack, which is awesome btw, or just using backslashes. Remember PEP 8 isn't a weapon to be wielded by a stern Auntie Tim Peters. 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. Cheers, -Barry

Guido van Rossum

3:38 p.m.

Clearly some people have interpreted this dogmatically as "never use backslashes", so I think we should explicitly update the PEP with more moderate language and an example. On Wednesday, July 3, 2013, Barry Warsaw wrote:

...

On Jul 02, 2013, at 06:37 PM, Matthew Lefavor wrote:

...
As you all know, Python supports a compound "with" statement to avoid the necessity of nesting these statements.

Unfortunately, I find that using this feature often leads to exceeding the 79-character recommendation set forward by PEP 8.

Yeah, I noticed and brought this up a while ago. I thought I filed a bug but can't find it. It would have been closed Won't Fix anyway.

As others have pointed out, you can usually rewrite such long with-statements to conform to the PEP 8 line lengths by e.g. saving the paths in a shorter named local variable), using Python 3.3's ExitStack, which is awesome btw, or just using backslashes. Remember PEP 8 isn't a weapon to be wielded by a stern Auntie Tim Peters.

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.

Cheers, -Barry

-- --Guido van Rossum (on iPad)

Barry Warsaw

3:48 p.m.

On Jul 03, 2013, at 08:38 AM, Guido van Rossum wrote:

...

Clearly some people have interpreted this dogmatically as "never use backslashes", so I think we should explicitly update the PEP with more moderate language and an example.

How about this: diff -r bd8e5c86fb27 pep-0008.txt --- a/pep-0008.txt Wed Jul 03 00:44:58 2013 +0200 +++ b/pep-0008.txt Wed Jul 03 11:46:07 2013 -0400 @@ -158,9 +158,19 @@ 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. Make sure to indent the continued line -appropriately. The preferred place to break around a binary operator -is *after* the operator, not before it. Some examples:: +for line continuation. + +Backslashes may still be appropriate at times. For example, long, +multiple ``with``-statements cannot use implicit continuation, so +backslashes are acceptable:: + + with open('/path/to/some/file/you/want/to/read') as file_1, \ + open('/path/to/some/file/being/written', 'w') as file_2: + file_2.write(file_1.read()) + +Make sure to indent the continued line appropriately. The preferred +place to break around a binary operator is *after* the operator, not +before it. Some examples:: class Rectangle(Blob):

Guido van Rossum

5:22 p.m.

Looks good, but I would add a mention of assert (without example) as another case where using a backslash may make sense. On Wed, Jul 3, 2013 at 8:48 AM, Barry Warsaw wrote:

...

On Jul 03, 2013, at 08:38 AM, Guido van Rossum wrote:

...
Clearly some people have interpreted this dogmatically as "never use backslashes", so I think we should explicitly update the PEP with more moderate language and an example.

How about this:

diff -r bd8e5c86fb27 pep-0008.txt --- a/pep-0008.txt Wed Jul 03 00:44:58 2013 +0200 +++ b/pep-0008.txt Wed Jul 03 11:46:07 2013 -0400 @@ -158,9 +158,19 @@ 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. Make sure to indent the continued line -appropriately. The preferred place to break around a binary operator -is *after* the operator, not before it. Some examples:: +for line continuation. + +Backslashes may still be appropriate at times. For example, long, +multiple ``with``-statements cannot use implicit continuation, so +backslashes are acceptable:: + + with open('/path/to/some/file/you/want/to/read') as file_1, \ + open('/path/to/some/file/being/written', 'w') as file_2: + file_2.write(file_1.read()) + +Make sure to indent the continued line appropriately. The preferred +place to break around a binary operator is *after* the operator, not +before it. Some examples::

class Rectangle(Blob):

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

Barry Warsaw

5:27 p.m.

On Jul 03, 2013, at 10:22 AM, Guido van Rossum wrote:

...

Looks good, but I would add a mention of assert (without example) as another case where using a backslash may make sense.

Done.

Ron Adam

4:56 p.m.

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. 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. For continued lines inside of function calls, and container literals, indenting the continued lines is enough in most cases. 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.) Cheers, Ron

Guido van Rossum

5:34 p.m.

On Wed, Jul 3, 2013 at 9:56 AM, Ron Adam 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)

Ron Adam

8:55 p.m.

On 07/03/2013 12:34 PM, Guido van Rossum wrote:

...

On Wed, Jul 3, 2013 at 9:56 AM, Ron Adam 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

Guido van Rossum

9:39 p.m.

On Wed, Jul 3, 2013 at 1:55 PM, Ron Adam wrote:

...

On 07/03/2013 12:34 PM, Guido van Rossum wrote:

...
On Wed, Jul 3, 2013 at 9:56 AM, Ron Adam wrote:

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.

Maybe you're talking about this case: instructions = [ 'foo', 'bar', 'very long line' # comma intentionally missing ' which is continued here', 'not so long line' # comma accidentally missing 'accidentally continued', 'etc.', ] I brought this up a few weeks or months ago, hoping to convince people that implicit string concatenation is evil enough to ban. I didn't get very far. But allowing backslashes here won't accomplish anything, because they are redundant. (In fact I get really mad when people use backslashes for continuation inside parens/brackets/braces. :-) -- --Guido van Rossum (python.org/~guido)

Ron Adam

11:57 p.m.

On 07/03/2013 04:39 PM, Guido van Rossum wrote:

...

Maybe you're talking about this case:

instructions = [ 'foo', 'bar', 'very long line' # comma intentionally missing ' which is continued here', 'not so long line' # comma accidentally missing 'accidentally continued', 'etc.', ]

I brought this up a few weeks or months ago, hoping to convince people that implicit string concatenation is evil enough to ban. I didn't get very far.

I'm +1 for that change BTW. It falls under the management category of how difficult it can be to get people to want to change how they think.

...

But allowing backslashes here won't accomplish anything, because they are redundant. (In fact I get really mad when people use backslashes for continuation inside parens/brackets/braces. :-)

But you did apparently feel the need to put verbose comments there to clarify the example. ;) Yes, the backslashes are redundant as far as the compiler goes, but they serve as hints to the human reader, (in the same way your comments did.), so I don't think they are completely redundant. New users would probably find the following easier to read because they don't yet think in terms of what the CPU is actually doing or not doing. That probably takes a few years of programming to reach that point. instructions = [ 'foo', 'bar', 'very long line' \ ' which is continued here', 'not so long line' \ ' accidentally continued', 'etc.', ] This doesn't bother me, each line has a meaningful ending to the reader, and there is no need for comments to make it clearer. And the number of backslashes is not excessive. I'm neutral on this, not need to recommend, or discourage it. It helps some people while, others find it unnecessary. It's a human thing, the compiler doesn't care. But this ... instructions = ( 'very, ' \ 'long, ' \ 'line with commas in, ' \ 'it to, ' \ 'seperate individual, ' \ 'items, ' \ 'etc, ' \ ) Now, this gets under my skin! This is definitely redundant. The missing comma case I saw was in a list several screen pages long with only a few lines continued, and one missing comma. I just can't recall which file it is. Meant to put it in the tracker, and still do once I find it again. I think I saw it in one of the encoding files. Cheers, Ron

Andrew Barnert

10:15 p.m.

On Jul 3, 2013, at 13:55, Ron Adam wrote:

...

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

Well, If you want inline comments on each line. But I don't think this is a serious issue, because I can't think of a case where it's likely to happen that implicit continuation in parens doesn't already take care of. (For example, calling a builtin with 8 non-keyword params, you probably want a comment next to each argument, but the arguments are already in parens.)

David Mertz

5:43 p.m.

This looks good... EXCEPT: On Wed, Jul 3, 2013 at 9:56 AM, Ron Adam wrote:

...

Use what obviously reads better. 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.

FEWER characters! Also "spanS 2 lines"

...

For continued lines inside of function calls, and container literals, indenting the continued lines is enough in most cases.

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

-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.

3948

Age (days ago)

3949

Last active (days ago)

List overview

Download

18 comments

8 participants

participants (8)

Andrew Barnert
Barry Warsaw
David Mertz
Guido van Rossum
João Bernardo
Matthew Lefavor
Nick Coghlan
Ron Adam

Parenthesized Compound With Statement

Matthew Lefavor

Matthew Lefavor

tags

participants (8)