[Python-ideas] Revised revised revised PEP on yield-from
greg.ewing at canterbury.ac.nz
Tue Feb 17 05:53:57 CET 2009
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
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
> 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
> And that could in turn be a generator with another such slot, 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
> 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.
More information about the Python-ideas