[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