[Python-ideas] Parenthesized Compound With Statement

Matthew Lefavor mclefavor at gmail.com
Wed Jul 3 07:29:15 CEST 2013


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 at 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?
>>
>> On Tue, Jul 2, 2013 at 3:37 PM, Matthew Lefavor <mclefavor at 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 at python.org
>> >> http://mail.python.org/mailman/listinfo/python-ideas
>> >
>> >
>> >
>> > --
>> > --Guido van Rossum (python.org/~guido)
>> > _______________________________________________
>> > Python-ideas mailing list
>> > Python-ideas at python.org
>> > http://mail.python.org/mailman/listinfo/python-ideas
>>
>
>
> --
> --Guido van Rossum (on iPad)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130703/2e17af13/attachment.html>


More information about the Python-ideas mailing list