[Stackless] Re: [Python-Dev] Stackless pages
Just van Rossum
just at letterror.com
Mon Nov 6 18:50:49 CET 2000
At 12:15 PM -0500 06-11-2000, Gordon McMillan wrote:
>I wasn't thinking of your coroutine extension when I wrote that
>(I said "coroutine class" after all).
I know, except that _using_ such a class is pretty much indistinguishable
from using my module, who's API was in fact heavily inspired by an earlier
proposal from Sam Rushing, written in Python.
(I found it impossible to implement it cleanly (ie. without causing cyclic
trash) with continuations as they are. The C version was almost a
no-brainer. Go figure.)
>I liked what I saw; and I still
>haven't had time to look closer. I thought of bringing it up, but
>since I am still largely ignorant of what you did, and (more
>importantly) the battle is on a completely different front right
>now, I didn't.
>The objections (whether the objectors have realized it yet or
>not) are to stackless precisely because it is stackless. There
>seems some acceptance of the value of uthreads, generators
>and coroutines. So the first two points to make are that all this
>stuff requires stackless (or something very like it) and
>stackless != the continuation module.
Right, how often do we have to repeat that? Continuations aren't even
needed to do full coroutining and uthreading. But, as Christian has put it
before, with Stackless you get continuations for free, and they're
fantastic study material.
>If we can't overcome "ew - a call might not ever return" there's
>not much sense in writing the PEPs.
What I didn't quite understand was that these (new) objections seem to be
about the C API: Stackless doesn't play _any_ C tricks, so I was under the
impression all C calls are garuanteed to return, no? On the Python level:
who cares, that's what continuations are for...
Stackless mailing list
Stackless at starship.python.net
More information about the Stackless