Most "active" coroutine library project?

Piet van Oostrum piet at
Sun Sep 27 12:18:21 CEST 2009

>>>>> Grant Edwards <invalid at invalid.invalid> (GE) wrote:

>GE> On 2009-09-25, Piet van Oostrum <piet at> wrote:
>>>>>>>> exarkun at (e) wrote:
>e> I specifically left out all "yield" statements in my version, since that's
>e> exactly the point here. :)  With "real" coroutines, they're not necessary -
>e> coroutine calls look just like any other call.  With Python's enhanced
>e> generators, they are.
>>> The first time I encountered coroutines was in Simula-67. Coroutine
>>> switching was certainly explicit there. IIRC, the keyword was resume.

>GE> I'm not sure exactly what "coroutine calls" refers to, but the
>GE> "mis-feature" in Python co-routines that's being discussed is
>GE> the fact that you can only yeild/resume from the main coroutine
>GE> function.

Yes, I know, but the discussion had drifted to making the yield
invisible, if I understood correctly.

>GE> You can't call a function that yields control back to the other
>GE> coroutine(s).  By jumping through some hoops you can get the
>GE> same effect, but it's not very intuitive and it sort of "feels
>GE> wrong" that the main routine has to know ahead of time when
>GE> calling a function whether that function might need to yield or
>GE> not.

I know. I think this is an implementation restriction in Python, to make
stack management easier. Although if you would lift this restriction
some new syntax would have to be invented to distinguish a generator
from a normal function.
Piet van Oostrum <piet at>
URL: [PGP 8DAE142BE17999C4]
Private email: piet at

More information about the Python-list mailing list