[Python-ideas] Cofunctions PEP - Revision 4

Andrey Popp 8mayday at gmail.com
Sat Aug 14 18:40:52 CEST 2010


Greg Ewing:
> M.-A. Lemburg wrote:
>> Sure, and those use Stackless to solve the problem, which IMHO
>> provides a much more Pythonic approach to these things.
> At the expense of using a non-standard Python installation,
> though. I'm trying to design something that can be incorporated
> into standard Python and work without requiring any deep
> black magic. Guido has so far rejected any idea of merging
> Stackless into CPython.

Note, that there is also greenlet library that provides such part of
functionality from Stackless (except preemptive scheduling and
pickling) and eventlet/gevent libraries that is quite popular
solutions for network applications written in Python, which use

> And I'm not sure what criteria to judge pythonicity by in
> all this. Stackless tasklets work without requiring any kind
> of function or call markers -- everything looks exactly
> like normal Python code. But Guido and others seem to be
> objecting to my implicit-cocall proposal on the basis that
> it looks *too much* like normal code. It seems to me that
> the same criticism should apply even more to Stackless.

For me the fact that greenlet code looks like normal code is more
preferable against generator-based coroutines (I think they are
overuse of generator syntax). Also I don't see the need to explicit

1) It will increase the complexity of language without necessity — we
have no special syntax for threading, so why we should have one for
cooperative threads? Semantics are almost the same relative to
unthreaded Python, except with cooperative threading we should
explicitly control execution, which has less semantic impact than
preemptive threading code, I think.

2) That will affect code reusability a lot, because we can't mix
cocalls and calls.

All this issues are solved with greenlet library and I think if Python
needs cooperative threads they should have API and behave like

Andrey Popp

phone: +7 911 740 24 91
e-mail: 8mayday at gmail.com

More information about the Python-ideas mailing list