[Python-Dev] Return from generators in Python 3.2 (original) (raw)

Bob Ippolito bob at redivi.com
Fri Aug 27 04:54:57 CEST 2010

On Fri, Aug 27, 2010 at 8:25 AM, Guido van Rossum <guido at python.org> wrote:

On Thu, Aug 26, 2010 at 5:05 PM, Yury Selivanov <yselivanov at gmail.com> wrote:

On 2010-08-26, at 8:04 PM, Greg Ewing wrote:

Even with your proposal, you'd still have to use a 'creepy abstraction' every time one of your coroutines calls another. That's why PEP 380 deals with 'more than just return'.

Nope.  In almost any coroutine framework you have a scheduler or trampoline object that basically does all the work of calling, passing values and propagating exceptions.  And many other things that 'yield from' won't help you with (cooperation, deferring to process/thread pools, pausing, etc.)  Being a developer of one of such frameworks, I can tell you, that I can easily live without 'yield from', but dealing with weird return syntax is a pain. That's not my experience. I wrote a trampoline myself (not released yet), and found that I had to write a lot more code to deal with the absence of yield-from than to deal with returns. In my framework, users write 'raise Return(value)' where Return is a subclass of StopIteration. The trampoline code that must be written to deal with StopIteration can be extended trivially to deal with this. The only reason I chose to use a subclass is so that I can diagnose when the return value is not used, but I could have chosen to ignore this or just diagnose whenever the argument to StopIteration is not None.

A bit off-topic, but...

In my experience the lack of "yield from" makes certain styles of programming both very tedious and very costly for performance. One example would be Genshi, which implements something like pipes or filters. There are many filters that will do something once (e.g. insert a doctype) and but have O(N) performance because of the function call overhead of "for x in other_generator: yield x". Nest this a few times and you'll have 10 function calls for every byte of output (not an exaggeration in the case of Trac templates). I think if implemented properly "yield from" could get rid of most of that overhead.

-bob

More information about the Python-Dev mailing list