[Python-ideas] Revised revised revised PEP on yield-from

[Greg Ewing]

Guido van Rossum wrote:

 > There better be a pretty darn good reason to do this.

I think that making it easy to use generators as
lightweight threads is a good enough reason.

 > I really don't
 > like overloading return this way -- normally returning from a
 > generator is equivalent to falling off the end and raises
 > StopIteration

It still is. It's just that if you happen to return a
value, it gets attached to the StopIteration for the
use of anything that wants to care. It will make no
difference at all to anything already existing.

Also, if a generator that returns something gets called
in a context that doesn't know about generator return
values, the value is simply discarded, just as with
an ordinary function call that ignores the return
value.

 > I'm not sure I like this interpretation of .send() -- it looks
 > asymmetrical with the way .send() to non-generator iterators is
 > treated in other contexts, where it is an error.

I wouldn't object to raising an exception in that case.
Come to think of it, doing that would me more consistent
with the idea of the caller talking directly to the
subgenerator.

 > And that could in turn be a generator with another such slot, right?

That's right.

 > Hopefully the testing for the presence of .throw, .send and .close
 > could be done once at the start of the yield-from and represented as a
 > set of flags.

Yes. You could even cache bound methods for these if you
wanted.

 > I recommend that you produce a working implementation of this; who
 > knows what other issues you might run into

Good idea. I'll see what I can come up with.

-- 
Greg