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

Greg Ewing 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
 > 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

 > 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?

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

 > 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 mailing list