[Python-Dev] PEP 334 - Simple Coroutines via SuspendIteration

[Phillip J. Eby]

At 09:30 PM 9/30/04 +0200, Leopold Toetsch wrote:
>Please note that that has nothing to do with "aync programming". Its just 
>like a GOTO, but w/o limitation where you'll branch to - or almost no 
>limitations: you can't cross C-stack boundaries on in other words you 
>can't branch to other incarnations of the run-loop. (Exceptions are a bit 
>more flexible though, but they still can only jump "up" the C-stack)
>
>Using CPS for function calls implies therefore a non-trivial rewrite of 
>CPython, which OTOH and AFAIK is already available as Stackless Python.

Clark is talking about a limited subset of CPS, where continuations are 
only single-use.  That is, a very limited form of continuations roughly 
equivalent in power to either Greenlets or a stack of generator-iterators.


>Making continuations usable at the language level is a different thing, 
>though.

Indeed, and luckily it isn't needed for PEP 334.  PEP 334 just needs the 
interpreter to be able to resume evaluation of a generator frame at any 
CALL opcode or "for" looping that invokes a generator-iterator's next() 
method, if SuspendIteration was raised.  I don't know if a corresponding 
operation for Jython is possible.

(In the case of CPython, this could be implemented via a type slot to check 
whether a callable object is "resumable", so that you actually *could* 
decorate suitable functions as being resumable, not just generator-iterator 
next() methods.)

Personally, I'm +0 (at most) on the PEP at the moment, as it doesn't IMO 
add much over using a generator stack, such as what I use in 
'peak.events'.  I'd be much more interested in a way to pass values and 
exceptions *into* generators, which would be more in line with what I'd 
consider "simple coroutines".

A mechanism to pass values or exceptions into generators would be let me 
replace the hackish
bits of 'peak.events' with clean language features, but I'm not sure PEP 
334 would give me enough to be worth reorganizing my code, as it's 
presently defined.

Also, I find the current PEP a confusing mishmash of references to various 
technologies (that are all harder to implement than what's actually 
desires) and unmotivating implementations of things I'd can't see wanting 
to do.  It would be helpful for it to focus on motivating usage examples 
(such as suspending a report while waiting for a database) *early* in the 
PEP, rather than burying them at the end.  And, most of the sample Python 
code looks to me like examples of how an implementation might work, but 
they don't illustrate the intended semantics well, nor do they really help 
with designing an implementation.  Finally, the PEP shouldn't call these 
co-routines, as co-routines are able to "return" values to other 
co-routines.  The title should be something more like "Resuming Generators 
after SuspendIteration", which much more accurately describes the scope of 
the desired result.