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