[Python-Dev] PEP 492 vs. PEP 3152, new round (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Apr 25 08:04:10 CEST 2015

On 25 April 2015 at 07:37, Łukasz Langa <lukasz at langa.pl> wrote:

On Apr 24, 2015, at 10:03 AM, Guido van Rossum <guido at python.org> wrote: 3. syntactic priority of await

Yury, could you tweak the syntax for await so that we can write the most common usages without parentheses? +1 Yury points out there was likely a reason this wasn’t the case for yield in the first place. It would be good to revisit that. Maybe for yield itself, too?

yield requires parentheses in most cases for readability purposes. For example, does this pass one argument or two to "f"?:

f(yield a, b)

Answer: neither, it's a syntax error, as you have to supply the parentheses to say whether you mean "f((yield a, b))" or "f((yield a), b)".

Requiring parentheses except in a few pre-approved cases (specifically, as a standalone statement and as the RHS of assignment statements) eliminated all that potential ambiguity.

Allowing "return yield a, b" and "return yield from a, b" by analogy with assignment statements would be fine, but getting more permissive than that with yield expressions doesn't make sense due to the ambiguity between yielding a tuple and other uses of commas as separators in various parts of the grammar.

PEP 492's "await" is a different case, as asynchronously waiting for a tuple doesn't make any sense. However, I'm not sure the grammar will let you reasonably express "anything except a tuple literal" as the subexpression after the await keyword, so it will likely still need special case handling in the affected statements in order to avoid "await a, b" being interpreted as waiting for a tuple.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list