[Python-Dev] Simple coroutines? (original) (raw)

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 mailing list