[Python-Dev] Coroutines (PEP 342)

Phillip J. Eby pje at telecommunity.com
Tue Nov 15 04:24:52 CET 2005

At 03:46 PM 11/14/2005 -0700, Bruce Eckel wrote:
>I just finished reading PEP 342, and it appears to follow Hoare's
>Communicating Sequential Processes (CSP) where a process is a
>coroutine, and the communicaion is via yield and send(). It seems that
>if you follow that form (and you don't seem forced to, pythonically),
>then synchronization is not an issue.
>What is not clear to me, and is not discussed in the PEP, is whether
>coroutines can be distributed among multiple processors.

If you were to write a trampoline that used multiple threads, *and* you 
were using a Python implementation that supported multiple processors (e.g. 
Jython, IronPython, ?), *and* that Python implementation supported PEP 342, 
then yes.

However, that just means the answer is, "if you can run Python code on 
multiple processors, you can run Python code on multiple processors".  PEP 
342 itself has nothing to say about that issue, which exists independently 
of the PEP.

So, the PEP doesn't address what you're asking about, because the GIL still 
exists in CPython, and will continue to exist.  Also, guaranteeing 
encapsulation of the coroutines would be *hard*, because lots of Python 
objects like modules, functions, and the like would be shared between more 
than one coroutine, and so then the issue of locking raises its ugly head 

>  If that is or
>isn't possible I think it should be explained in the PEP, and I'd be
>interested in know about it here (and ideally why it would or wouldn't

The PEP is entirely unrelated (and entirely orthogonal) to whether a given 
Python implementation can interpret Python code on multiple processors 

The only difference between what PEP 342 does and what Twisted does today 
is in syntax.  PEP 342 just provides a syntax that lets you avoid writing 
your code in CPS (continuation-passing style) with lots of callbacks.

PEP 342 is implemented in the current Python SVN HEAD, by the way, if you 
want to experiment with the implementation.

More information about the Python-Dev mailing list