Generators versus Coroutines

Timothy Fitz firemoth at
Mon Aug 16 06:37:20 CEST 2004

Lenard Lindstrom <len-1 at> wrote in message news:<zn4w2y3g.fsf at>...
> Nick Patavalis <npat at> writes:
> > On 2004-08-14, Paul Rubin <> wrote:
> > >
> > > You can't yield across multiple levels of function calls.  That's why
> > > they're called "simple generators" instead of just "generators".
> > >
> > 
> > For me it would be *tremendously* usefull if one could yield across
> > multiple levels of function calls. If this was supported, then most
> > uses of O/S treads could be replaced by generators.
> > 
> > Does anyone know if such a feature is planned?
> > 
> Having followed the development of Prothon it is my understanding that
> such a thing is not possible in CPython for two reasons. The first is
> that the yield statement itself defines a function declaration as a
> generator. Without a specific "gen" declarator keyword as in Prothon:
> gen evens(n):    # This is a generator
>     for i in n:  # "for i in range(n)" in Python
>         doubleit(i)
> def doubleit(i)  # This is a helper that yields
>     yield(2 * x) # "yield 2 * x"
> for i in evens(5):
>     print(i)     # "print i"
> the yield does not know how many function calls up it must go to return
> a value. In CPython it simply saves one frame, that of the current function
> call. The second reason is a python function call in CPython involves an
> actual recursive C call of the interpreter. So to have a yield span more
> than one python function would require saving and restoring part of the
> actual C stack - coroutines at the C level - or a rewrite of the interpreter
> to not make the recursive C calls as in Stackless Python.
> Lenard Lindstrom
> <len-l at>

I disagree, it seems to me I could make a pure python based
implementation with some funky state handling classes and exceptions.
Granted, it wouldn't look nice (all your 'locals' would be in an
object, and you'd have to call like tyield())

More information about the Python-list mailing list