[Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3 (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Wed Nov 9 12:21:45 CET 2011
- Previous message: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
- Next message: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, Nov 9, 2011 at 8:59 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
Nick Coghlan wrote:
I'll add a new test to ensure "yield from x" requires parentheses whenever "yield x" requires them (and fix the Grammar file on the implementation branch accordingly). Wait a minute, there's nothing in the PEP as accepted that mentions any such restriction.
It doesn't need to be mentioned in the PEP - it's inherited due to the fact that the PEP builds on top of yield expressions. There is no excuse for the two expressions being inconsistent in their parenthesis requirements when they are so similar syntactically.
For ordinary yield expressions, "f(yield x, y)" has to be disallowed since it is genuinely ambiguous (does it mean "f(yield (x, y))" or "f((yield x), y)"?), and it then becomes something of a pain to allow any yield argument other than an unparenthesised tuple when a yield expression is provided as the sole argument to a call.
So, from my point of view, it is absolutely a requirement that 'yield from' expressions be parenthesised in the multiple argument case. The previous grammar allowed confusing constructs like "f(yield from x, y)" (interpreting it as "f((yield from x), y) while still issuing a syntax error (as expected) for "yield from x, y".
You could try to make a case that we should allow "f(yield from x)", but it isn't then clear to the casual reader why that's OK and "f(yield x)" gets disallowed. And that brings us back to the complexity of creating a special yield expression variant that's allowed as the sole argument to a function call without additional parentheses, but without introducing ambiguity into the grammar.
It's simpler and cleaner to just make the rules for the two constructs identical - if it's a subexpression, you have to add the extra parentheses, if it's a statement or the sole expression on the RHS of an assignment, you don't.
That said, it's likely possible to make those parentheses optional in the single argument call case (as we do for generator expressions), but do you really want to hold up the PEP 380 implementation for a minor detail like that? Besides, since it would affect the grammar definition for ordinary yield expressions as well, it might even need a new PEP.
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
- Next message: [Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]