[Python-Dev] Simple coroutines?
Phillip J. Eby
pje at telecommunity.com
Tue Aug 24 13:34:10 CEST 2004
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.
More information about the Python-Dev