[Python-Dev] 'stackless' python?
M.-A. Lemburg
mal at lemburg.com
Thu May 13 10:23:13 CEST 1999
rushing at nightmare.com wrote:
>
> [list has been quiet, thought I'd liven things up a bit. 8^)]
Well, there certainly is enough on the todo list... it's probably
the usual "ain't got no time" thing.
> I'm not sure if this has been brought up before in other forums, but
> has there been discussion of separating the Python and C invocation
> stacks, (i.e., removing recursive calls to the intepreter) to
> facilitate coroutines or first-class continuations?
Wouldn't it be possible to move all the C variables passed to
eval_code() via the execution frame ? AFAIK, the frame is
generated on every call to eval_code() and thus could also
be generated *before* calling it.
> One of the biggest barriers to getting others to use asyncore/medusa
> is the need to program in continuation-passing-style (callbacks,
> callbacks to callbacks, state machines, etc...). Usually there has to
> be an overriding requirement for speed/scalability before someone will
> even look into it. And even when you do 'get' it, there are limits to
> how inside-out your thinking can go. 8^)
>
> If Python had coroutines/continuations, it would be possible to hide
> asyncore-style select()/poll() machinery 'behind the scenes'. I
> believe that Concurrent ML does exactly this...
>
> Other advantages might be restartable exceptions, different threading
> models, etc...
Don't know if moving the C stack stuff into the frame objects
will get you the desired effect: what about other things having
state (e.g. connections or files), that are not even touched
by this mechanism ?
--
Marc-Andre Lemburg
______________________________________________________________________
Y2000: Y2000: 232 days left
Business: http://www.lemburg.com/
Python Pages: http://starship.python.net/crew/lemburg/
More information about the Python-Dev
mailing list