Parenthesized Compound With Statement
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
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 <mclefavor@gmail.com> 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)
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 <mclefavor@gmail.com> 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
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 <mclefavor@gmail.com<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)
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 <guido@python.org> 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 <mclefavor@gmail.com> 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)
On 3 July 2013 15:29, Matthew Lefavor <mclefavor@gmail.com> 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
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
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)
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):
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 <barry@python.org> 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)
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
On Wed, Jul 3, 2013 at 9:56 AM, Ron Adam <ron3200@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)
On 07/03/2013 12:34 PM, Guido van Rossum wrote:
On Wed, Jul 3, 2013 at 9:56 AM, Ron Adam <ron3200@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
On Wed, Jul 3, 2013 at 1:55 PM, Ron Adam <ron3200@gmail.com> wrote:
On 07/03/2013 12:34 PM, Guido van Rossum wrote:
On Wed, Jul 3, 2013 at 9:56 AM, Ron Adam <ron3200@gmail.com> 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)
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
On Jul 3, 2013, at 13:55, Ron Adam <ron3200@gmail.com> 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.)
This looks good... EXCEPT: On Wed, Jul 3, 2013 at 9:56 AM, Ron Adam <ron3200@gmail.com> 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.
participants (8)
-
Andrew Barnert -
Barry Warsaw -
David Mertz -
Guido van Rossum -
João Bernardo -
Matthew Lefavor -
Nick Coghlan -
Ron Adam