[Python-ideas] Proto-PEP on a 'yield from' statement

[Greg Ewing]

Bruce Frederiksen wrote:

> But the yield from form causes g(x) to send output to the caller, which 
> f(x) doesn't do.

In the usage I'm talking about there, you're not interested
in the values being yielded. You're using yields without
arguments as a way of suspending the thread.

So you're not calling g() for the purpose of yielding
values. You're calling it for the side effects it produces,
and/or the value it returns using a return statement --
the same reasons you were calling f() in the non-thread
version.

There are also cases where you do want to use the yielded
values. For example if you have a function acting as a
consumer, and a generator acting as a producer. The
producer may want to spread its computation over several
functions, but all the produced values should still go
to the consumer.

The same consideration applies if you're using send() to
push values in the other direction. In that case, the
outer function is the producer and the generator is the
consumer. Whenever the consumer wants to get another
value, it does a yield -- and the value should come from
the producer, however deeply nested the yield call is.

There are, of course, cases where this is not what you
want. But in those cases, you don't use a 'yield from'
expression -- you use a for-loop or explicit next() and
send() calls to do whatever you want to do with the
values being passed in and out.

> This is why I think that it's important to 
> separate the aspects of sending and receiving values to/from 
> generators.  That's why I proposed receive, rather than the yield 
> expression, to accept values in the generator.

There may be merit in that, but it's a separate issue,
outside the scope of this PEP. And as has been pointed out,
if such a change is ever made, it will carry over naturally
into the semantics of 'yield from'.

-- 
Greg