[Python-Dev] Simple coroutines?

[Clark C. Evans]

I'm not tied to my proposal, I'm suggesting that if the scope of
continuations is limited to only work with iterators, that a solution
may emerge.  This limitation, in pratice with generator syntax, is not
all that bothersome to an application developer.

On Wed, Aug 25, 2004 at 12:13:46PM -0400, Phillip J. Eby wrote:
| At 02:51 PM 8/25/04 +1200, Greg Ewing wrote:
| >> 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.
| >
| >Actually, it probably wouldn't be too hard to make exceptions
| >resumable -- provided all the frames in between are Python. If the
| >exception gets thrown through any C calls, though, resumption becomes
| >impossible.  Some other structure is needed to hold the state of a
| >resumable C call.
| 
| Unfortunately, as was discussed on the previous Stackless thread, nearly 
| *all* Python bytecodes pass through C on their way to other Python code.

However, the C code in the distribution could be scrubbed to make sure
that it works with the mechanism.  And the C API could be detailed so
that this case is managable; else, it is an "uncaught" exception.

| I'm going to have to think about this one some more, but it seems to me 
| that it would be much easier to add bidirectional communication to 
| generators to create a coroutine type, than to try to implement resumable 
| exceptions.

Sure; but resumable exceptions would only need to operate with generators,
and there are some simple rewrite tricks one could do.  If an iterator is
calling a generator it could be re-written in a form that maintains state
and _doesn't_ catch the exception.   Already for generators 'finally'
blocks are troublesome, so this doesn't change things for the worse.
StopIteration has many of these same issues.

On Wed, Aug 25, 2004 at 03:32:28PM +1200, Greg Ewing wrote:
| > You'd definately want to mix them.  For example, a 'cooperator'
| > would be reading from a socket, it could do one of three things:
| > 
| >   yield the next line from the sender
| >   raise StopIteration if the socket closed
| >   raise SuspendIteration if the read() is blocked
| 
| Hmmm. It seems that generation and cooperation are really orthogonal
| concepts -- you may want something that is both a generator *and* a
| cooperator. My proposal doesn't allow for this. I will have to do some
| more thinking...

Not only othogonal, but quite complementary.

Kind Regards,

Clark

-- 
Clark C. Evans                      Prometheus Research, LLC.
                                    http://www.prometheusresearch.com/
    o                               office: +1.203.777.2550 
  ~/ ,                              mobile: +1.203.444.0557 
 //
((   Prometheus Research: Transforming Data Into Knowledge
 \\  ,
   \/    - Research Exchange Database
   /\    - Survey & Assessment Technologies
   ` \   - Software Tools for Researchers
    ~ *