Generators versus Coroutines

[Michael Sparks]

On 16 Aug 2004, Bryan Olson wrote:

> Michael Sparks:
> > On Sun, 15 Aug 2004, Nick Patavalis wrote:
> > ...
> > > For me it would be *tremendously* usefull if one could yield across
> > > multiple levels of function calls. If this was supported, then most
> > > uses of O/S treads could be replaced by generators.
> >
> > You can do this already if you use Armin Rigo's Greenlets which, whilst
> > included in Stackless appear to work perfectly fine with standard python.
> > (I've only tested with 2.3 FWIW)
>
> Correct me if I'm wrong: Greenlets use a c-language extension to
> do the routine switching; implementing the same in pure Python is
> infeasable.

Correct. I never claimed that doing this in "pure" python was possible -
largly because I think such a concept is pretty silly.

After all, what is "pure" anyway?
   * Is using a module that comes with python allowed?
   * If so is using a module written in C acceptable?
      * If so what if greenlets gets included at some point in time, do
        modules included cease being "pure", or would greenlets be
        redefined?.
      * Also if using a builtin module written in C is "pure" then why are
        modules written in C not included not "pure"?
      * You might conclude then that "pure" python couldn't use
        modules written in C whether included with the interpreter or not.
  * If you conclude that what about the python interpreter? That'ss
     written in C, so *that's* not pure if you mean code that only using
     python anywhere in the system. (if you allow the interpreter, why
     not modules that come with it?)

You just end up (IMO) having contradictory arguments about purity if you
go down that route. After all someone has proposed using threads as a pure
implementation. Is *that* "pure"? Is the threading code written in python
or C? (Looks like C on my system - but it's declared "pure" ;-)

IMO, the question is one of practicality. It is practical to use
generators to build concurrent systems - and it works pretty well. If
that's not good enough it is practical to using concurrency implementated
as an extension to python. If that's not good enough, it is practical to a
different implementation of python. Or if concurrency in a single thread
isn't sufficient you can change to threads or processes.

I prefer "practical python" over "pure python" ;-)

> Generators rock, but they have a shadow of the power of co-routines.
> Continuations are more powerful still.

And if you choose appropriate coding conventions every problem domain that
co-routines and continuations can solve, generators can be used with
almost equal effectiveness.

Having written large amounts of code using generators to gain parallelism
in a single thread I don't say that lightly. I've found their simplicity
useful for limiting the complexity of the architecture. After all if any
piece of software is use for any length of time maintainability comes
before elegance. (unfortunately the two don't always go hand in hand)

Teasingly, ;-)


Michael