[Python-ideas] Allow parentheses to be used with "with" block

Andrew Barnert abarnert at yahoo.com
Mon Feb 16 23:09:58 CET 2015


On Feb 16, 2015, at 4:41, Martin Teichmann <lkb.teichmann at gmail.com> wrote:

> Hi everyone,
> 
> just to toss in my two cents: I would add a completely different way
> of line continuation. We could just say "if a line ends in an operator,
> it is automatically continued (as if it was in parentheses).
> 
> That would allow things like like:
> 
> something_long = something_else +
>   something_more
> 
> this would remove the need for many parentheses. It's also not a problem,
> as at least until now, a line cannot legally end in an operator (except
> when continued).

In addition to the other problems mentioned, comma is not an operator in Python, it's a delimiter, like a dot, semicolon, or parenthesis. It doesn't have a precedence or meaning of its own; it's used in multiple different expression and statement rules in similar but independent ways. (The docs do loosely refer to its use within an expression list as an operator at least once, but it's not parsed that way; an expression list has commas as part of its syntax.)

I realize that in C and its descendants, comma _is_ an operator, which is ambiguous with the use of commas in calls, declarations, etc. This is one of a half-dozen reasons that C can only be parsed with a powerful algorithm like GLR, or by adding a bunch of special-case hacks to a weaker parser. I don't think Python would benefit from becoming as hard to parse as C.

> Well, there is one exception: a line may indeed end in a , (comma).

Some lines may end in an expression list, and an expression that ends in a trailing comma. I don't think any other uses of comma can appear at the end of a line.

> So I would add another rule: only if a line starts with any of
> assert, from, import or with, comma continues a line.

What if it starts with an indent or dedent followed by one of those keywords?

> I was thinking about how that could be a problem. A comma at
> the end of a line currently means we're creating a tuple. So no
> problem with from and import. Also no problem with with, as
> it would have to be followed by a colon and a tuples in with
> statements also doesn't make much sense. With assert,
> this is interestingly already illegal, writing
> 
>   assert False, 3,
> 
> gives a syntax error (why, actually?)

Because the assert statement takes either a test expression, or a test expression and a message expression separated by a comma. Not an expression list. So there's nothing that trailing comma could plausibly be parsed as part of.

Note that with your change, the assert would now suck up the next line and try to parse something like "3, print(foo)" as an expression and give a confusing error message telling you that print(foo) is invalid syntax. People already have enough trouble learning how to deal with those errors from unbalanced parens; making them appear all over the place implicitly would make Python a lot harder for novices.

> All of what I propose can probably be done in the lexer already.
> 
> Those rules sound rather arbitrary, but well, once used I guess
> people won't even notice they exist.
> 
> Greetings
> 
> Martin
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/


More information about the Python-ideas mailing list