[Python-Dev] Return from generators in Python 3.2

[Bob Ippolito]

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