Allow with (x as y, z as w):

Hi, I have a problem: I've got code that has a `with` statement with multiple long names, so I have to break the line awkwardly using the \ character: with some_darn_object.my_long_named_method_on_it(argument='yep') as foo, \ a_different_darn_object.and_yet_another_method() as bar: I tried wrapping the context managers in parentheses, but it looks like it's not legal syntax: File "<stdin>", line 1 with (some_darn_object.my_long_named_method_on_it(argument='yep') as foo, ^ SyntaxError: invalid syntax Another demonstration from the REPL: Python 3.5.1 (v3.5.1:37a07cee5969, Dec 6 2015, 01:54:25) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information.
with (x as y, z as w): pass
File "<stdin>", line 1 with (x as y, z as w): pass ^ SyntaxError: invalid syntax I wish this syntax to be legal. Thanks, Ram.

Ram, This request has come up a couple of times before. See the following prior discussions: - https://mail.python.org/pipermail/python-ideas/2010-September/008021.html <https://mail.python.org/pipermail/python-ideas/2010-September/008021.html> - https://mail.python.org/pipermail/python-dev/2014-August/135741.html <https://mail.python.org/pipermail/python-dev/2014-August/135741.html> The upshot is: the restriction on context managers with parentheses like this is relatively likely to stick around. There have been discussions about the relative ambiguity of the syntax you’re using here compared with the syntax of tuples, and some suggestions that it’ll make life particularly tricky for the parser. I don’t have anything to add to those discussions, just wanted to suggest you may want to familiarise yourself with the previous times we had this conversation before continuing it. Cory

Also, I think some people are too fundamentalist about rejecting all uses of \ to break long lines. When combined with proper indentation of the continuation line, if there is no alternative, I think it looks better than artifically introduced parentheses. At least if there's only one or two continuation lines. E.g. ``` very_long_variable_name = \ very_long_function(very_long_argument_list) ``` looks better to me than ``` very_long_variable_name = ( very_long_function(very_long_argument_list)) ``` I'm just saying, there's a reason PEP 8's motto is "A Foolish Consistency is the Hobgoblin of Little Minds". On Tue, Apr 26, 2016 at 8:22 AM, Barry Warsaw <barry@python.org> wrote:
-- --Guido van Rossum (python.org/~guido)

Ram, This request has come up a couple of times before. See the following prior discussions: - https://mail.python.org/pipermail/python-ideas/2010-September/008021.html <https://mail.python.org/pipermail/python-ideas/2010-September/008021.html> - https://mail.python.org/pipermail/python-dev/2014-August/135741.html <https://mail.python.org/pipermail/python-dev/2014-August/135741.html> The upshot is: the restriction on context managers with parentheses like this is relatively likely to stick around. There have been discussions about the relative ambiguity of the syntax you’re using here compared with the syntax of tuples, and some suggestions that it’ll make life particularly tricky for the parser. I don’t have anything to add to those discussions, just wanted to suggest you may want to familiarise yourself with the previous times we had this conversation before continuing it. Cory

Also, I think some people are too fundamentalist about rejecting all uses of \ to break long lines. When combined with proper indentation of the continuation line, if there is no alternative, I think it looks better than artifically introduced parentheses. At least if there's only one or two continuation lines. E.g. ``` very_long_variable_name = \ very_long_function(very_long_argument_list) ``` looks better to me than ``` very_long_variable_name = ( very_long_function(very_long_argument_list)) ``` I'm just saying, there's a reason PEP 8's motto is "A Foolish Consistency is the Hobgoblin of Little Minds". On Tue, Apr 26, 2016 at 8:22 AM, Barry Warsaw <barry@python.org> wrote:
-- --Guido van Rossum (python.org/~guido)
participants (4)
-
Barry Warsaw
-
Cory Benfield
-
Guido van Rossum
-
Ram Rachum