[Python-Dev] [SPAM: 3.000] [issue11682] PEP 380 reference implementation for 3.3
Guido van Rossum
guido at python.org
Wed Nov 9 16:54:46 CET 2011
I see this as inevitable. By the time the parser sees 'yield' it has
made its choices; the 'from' keyword cannot modify that. So whenever
"yield expr" must be parenthesized, "yield from expr" must too. (And
yes, there are parsing systems that don't have this restriction. But
Python's does and we like it that way.)
At the same time, "yield expr, expr" works; but does "yield from expr,
expr" mean anything?
Finally, glad to see work on this PEP proceeding; I'm looking forward
to using the fruits of that labor!
On Wed, Nov 9, 2011 at 3:21 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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
>> 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.
> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
--Guido van Rossum (python.org/~guido)
More information about the Python-Dev