[Python-ideas] return value of yield expressions

Guido van Rossum guido at python.org
Tue Sep 13 17:56:12 CEST 2011


On Tue, Sep 13, 2011 at 6:00 AM, H. Krishnan <hetchkay at gmail.com> wrote:
> In the particular situation of send() --> yield, one could do something like
> (forgeting the backward compatibility with respect to the return value):

> gen.send(2, a2=3, e=5)

> and in the gen:
> (a1, a2, a3 = 3, *args, **kwds) = (yield <expr>)

What on earth is this syntax supposed to mean? Never mind that there's
a yield on the RHS; it is just a parenthesized expression so it could
could be any other function. What on earth do you expect to happen
with the syntax on the left, i.e. with the part

(a1, a2, a3 = 3, *args, **kwds) = ........whatever........

???????

It seems to me that changes to send() could be proposed that allow
.send() without argument or with multiple (positional) arguments, but
this would just make the yield expression return a tuple. It is not
unprecedented that foo() == foo(None), nor is it inconceivable that
bar(x, y) == bar((x, y)). This is not so different from the
equivalence between "x = 1, 2" and "x = (1, 2)". Do note that there's
perhaps a bit of an odd case where g.send((1,)) should yield a
1-tuple, whereas g.send(1,) would be equivalent to g.send(1) and hence
just send the value 1, not wrapped in a tuple. That this wasn't
proposed in the original PEP 342 was probably just a matter of keeping
things simple -- which I am still in favor of, and barring a lot more
evidence of how incredibly useful the proposed enhancement would be
(with *real* use cases, not made-up examples!) I will remain -0 on the
proposal of allowing different argument counts to .send().

But this business with argument unpacking syntax is different. It
seems poorly thought through. Syntax proposals like this often fail
because the proposer does not actually understand how Python's parser
works and how it is constrained, intentionally, to limited look-ahead
and no compile-time knowledge of the types of the values being passed
around at runtime. Also keep in mind orthogonality -- (yield <expr>)
should be usable anywhere: in an expression, in an if-statement, in a
return statement, in a function argument, in an index, as an operand
of a built-in operator, etc. You can't have a grammar where the syntax
for the left-hand side of the assignment symbol has a different syntax
depending on whether the righ-hand side contains a (yield <expr>) or
not.

-- 
--Guido van Rossum (python.org/~guido)



More information about the Python-ideas mailing list