Generators versus Coroutines

[Paul Rubin]

Michael Sparks <zathras at thwackety.com> writes:
> 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?

Yes

>    * If so is using a module written in C acceptable?

Only if it comes with Python

>       * If so what if greenlets gets included at some point in time, do
>         modules included cease being "pure", or would greenlets be
>         redefined?.

I don't understand.  Something using greenlets is impure now but becomes
pur eif greenlets gets included.

>       * Also if using a builtin module written in C is "pure" then why are
>         modules written in C not included not "pure"?

Because "Python" is what you get when you install the Python distro,
so anything included with the distro is Python no matter what language
it's written in.  Anything not included with the distro is only Python
if it's written in Python.

>       * You might conclude then that "pure" python couldn't use
>         modules written in C whether included with the interpreter or not.

No, pure includes C modules included with the interpreter.

>   * 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?)

The modules that come with the interpreter are allowed and they count
as pure.  Put another way, pure means any module you can run after
installing the Python distro, without having to run anything except
the Python distro (i.e. no C compiler).  Maybe someday the Python
distro will include a C compiler.  If that happens, then all C modules
will become pure.  Until then, only the C modules that are made
available through the Python installation process count as pure.

> 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.

> 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.  Switching between OS threads needs context
switching in and out of the kernel.  Coroutines are supposed to be
more like function calls in terms of overhead.  Simulating them with
OS threads is like simulating register loads and stores with XML
transactions over the internet.

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

Practical python very often means you have a Python distro that
someone else installed.  Whatever it can run, you can run, and
whatever it can't run, you can't run.  You don't get a C compiler.
That's why the concept of "pure Python" is meaningful and important.

> 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.