[Python-ideas] yield from multiple iterables (was Re: The async API of the future: yield-from)

Guido van Rossum guido at python.org
Fri Oct 19 19:18:38 CEST 2012

On Fri, Oct 19, 2012 at 9:50 AM, Christian Tismer <tismer at stackless.com> wrote:
> On 19.10.12 18:07, Guido van Rossum wrote:
>> On Fri, Oct 19, 2012 at 5:05 AM, Christian Tismer <tismer at stackless.com>
>> wrote:
>>> On 19.10.12 07:15, Greg Ewing wrote:
>>>> Christian Tismer wrote:
>>>>> - generators are able to free the stack, when they yield. But when they
>>>>>     are active, they use the full stack. At least when I follow the
>>>>> pattern
>>>>>     "generator is calling sub-generator".
>>>>>     A deeply nested recursion is therefore something to avoid. :-(
>>>> Only if yield-from chains aren't optimised the way they
>>>> used to be.
>>> Does that mean a very deep recursion would be efficient?
>> TBH, I am not interested in making very deep recursion work at all. If
>> you need that, you're doing it wrong in my opinion.
> Misunderstanding I think. Of course I don't want to use deep recursion.
> But people might write things that happen several levels deep and
> then iterating over lots of stuff. A true generator would have no
> problem with that.

Okay, good. I agree that this use case should be as fast as possible
-- as long as we still see every frame involved when a traceback is

> Assume just five layers of generators that have to be re-invoked
> for a tight yielding loop is quite some overhead that can be avoided.
> The reason why I care is that existing implementations that use
> greenlet style could  be turned into pure python, given that I manage
> to write the right support functions, and replace all functions by
> generators that emulate functions with async behavior.
> It would just be great if that worked at the same speed, independent
> from at which stack level an iteration happens.


> Agreed that new code like that would be bad style.

Like "what"?

--Guido van Rossum (python.org/~guido)

More information about the Python-ideas mailing list