[Python-Dev] 'stackless' python?

Tim Peters tim_one at email.msn.com
Sat May 15 18:43:20 CEST 1999


[Christian Tismer]
> ...
> But on the general issues:
> Can the Python-calls-C and C-calls-Python problem just be solved
> by turning the whole VM state into a data structure, including
> a Python call stack which is independent? Maybe this has been
> mentioned already.

The problem is that when C calls Python, any notion of continuation has to
include C's state too, else resuming the continuation won't return into C
correctly.  The C code that *implements* Python could be reworked to support
this, but in the general case you've got some external C extension module
calling into Python, and then Python hasn't a clue about its caller's state.

I'm not a fan of continuations myself; coroutines can be implemented
faithfully via threads (I posted a rather complete set of Python classes for
that in the pre-DejaNews days, a bit more flexible than Icon's coroutines);
and:

> This would automagically produce ICON iterators (duck)
> and coroutines (cover).

Icon iterators/generators could be implemented today if anyone bothered
(Majewski essentially implemented them back around '93 already, but seemed
to lose interest when he realized it couldn't be extended to full
continuations, because of C/Python stack intertwingling).

> If I guess right, continuation passing could be done
> by just shifting tiny tuples around. Well, Tim, help me :-)

Python-calling-Python continuations should be easily doable in a "stackless"
Python; the key ideas were already covered in this thread, I think.  The
thing that makes generators so much easier is that they always return
directly to their caller, at the point of call; so no C frame can get stuck
in the middle even under today's implementation; it just requires not
deleting the generator's frame object, and adding an opcode to *resume* the
frame's execution the next time the generator is called.  Unlike as in Icon,
it wouldn't even need to be tied to a funky notion of goal-directed
evaluation.

don't-try-to-traverse-a-tree-without-it-ly y'rs  - tim






More information about the Python-Dev mailing list