[Python-Dev] Simple coroutines?

[Phillip J. Eby]

At 05:57 PM 8/24/04 +1200, Greg Ewing wrote:
>What think ye all?

I don't think it's in the right direction to achieve the effects desired by 
Clark or me.  Here's a metaphor for what would be ideal: resumable 
exceptions.  If you could throw a special kind of exception (or even a 
regular exception), and call traceback.resume() to pick up execution at the 
point where it was thrown, whether thrown by a generator or a regular 
function.  If you had that capability, you could implement any sort of 
coroutine or task-switching facilities you wanted.

Without such a facility, one needs a stack of *ators to emulate it, to 
provide the effects desired by Clark's Flow or by peak.events.  However, 
co-operators' "suspend" doesn't provide a way to communicate between 
co-operators.  At least 'yield' lets you yield a value.  What's really 
needed (IMO) is to add a way to communicate *into* a co-operator, passing 
it a value to "accept" or a traceback to raise.  E.g.:

     input = suspend output

Where 'output' is returned from the current 'run()', and 'input' is a value 
passed to the next 'run()'.  Or, if there's a type/value/traceback passed 
to a 'throw()' method, then the 'suspend' statement should raise an error.

With that facility, 'peak.events' could drop the 'events.resume()' magic 
function.  It'd still need a stack of co-operators, and there'd still be 
ugliness when iterating over a generator that needed to be 
suspendable.  But at least it would be able to have clean syntax.  (Though 
I don't think that 'input=suspend output' is actually clean syntax, it's 
just better than the yield/resume thing.)

Anyway, as I said, what would be *most* useful for async programming is a 
way to resume a traceback, because then you wouldn't need for every 
intervening frame to have special suspension capability.