[Python-Dev] PEP 492 vs. PEP 3152, new round

[Nick Coghlan]

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