Generators versus Coroutines

[Michael Sparks]

On 17 Aug 2004, Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:
...
> No, pure includes C modules included with the interpreter.

See, this I find a ridiculous assertion. After all the modules that get
included changes. That means one week one implementation will be viewed as
impure and the next week pure. That's why I think the whole notion of
purity is ridiculous.

> > IMO, the question is one of practicality. It is practical to use
> > generators to build concurrent systems - and it works pretty well.
>
> Not Python generators.  Generators in other languages, maybe.

I'm sorry, I find it practical and works well. YMMV.

> > 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.
>
> No that's ridiculous.

No it's not. It's is _practical_ depending on what your uses for
concurrency are.

> Simulating them with
> OS threads is like simulating register loads and stores with XML
> transactions over the internet.

Wonderful hyperbole. (not being sarky, really is meant as a compliment :)
You've got to admit that's pretty extreme hyperbole. :)

> > 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.
>
> No, not Python generators, they're amazingly useful, but they're much
> less powerful than first class continuations.

I'm sorry, but this is completely false. At the end of the day these
things are all implemented on systems that do not have co-routines or
innate concurrency - ie assembler. All have the same "power".  (But *that*
depends on your definition...) It's just a matter of how much effort you
have to expend. In my experience, generators can be used with almost equal
effectiveness. (Note: not equal, I didn't and am not saying that)
Effectiveness != power.

I do agree though that "practical python" includes what a user of the code
has access to, however this depends heavily on the target environment.

If you're distributing just source to people then yes, what comes with the
interpreter is important. However stating something is "pure python" is
misleading - since there are so many potential different "pure python"
things out there. eg many hosting companies only have python 1.5.X loaded,
if at all, so anything written after that isn't "pure python" to someone
wanting to run something there. Personally I find the phrase more
misleading than useful. Your milage obvious varies :)

If however you are building a tool internal to your company, then what's
practical is very different. etc...

I doubt we're going to agree anytime soon though on much of this, so I'll
leave it there.

Best Regards,


Michael.