[Python-Dev] 'stackless' python?

[Guido van Rossum]

Interesting topic!  While I 'm on the road, a few short notes.

> I thought Guido was working on that for the mobile agent stuff he was
> working on at CNRI.

Indeed.  At least I planned on working on it.  I ended up abandoning
the idea because I expected it would be a lot of work and I never had
the time (same old story indeed).

Sam also hit it on the nail: the hardest problem is what to do about
all the places where C calls back into Python.

I've come up with two partial solutions: (1) allow for a way to
arrange for a call to be made immediately after you return to the VM
from C; this would take care of apply() at least and a few other
"tail-recursive" cases; (2) invoke a new VM when C code needs a Python
result, requiring it to return.  The latter clearly breaks certain
uses of coroutines but could probably be made to work most of the
time.  Typical use of the 80-20 rule.

And I've just come up with a third solution: a variation on (1) where
you arrange *two* calls: one to Python and then one to C, with the
result of the first.  (And a bit saying whether you want the C call to 
be made even when an exception happened.)

In general, I still think it's a cool idea, but I also still think
that continuations are too complicated for most programmers.  (This
comes from the realization that they are too complicated for me!)
Corollary: even if we had continuations, I'm not sure if this would
take away the resistance against asyncore/asynchat.  Of course I could 
be wrong.

Different suggestion: it would be cool to work on completely
separating out the VM from the rest of Python, through some kind of
C-level API specification.  Two things should be possiblw with this
new architecture: (1) small platform ports could cut out the
interactive interpreter, the parser and compiler, and certain data
types such as long, complex and files; (2) there could be alternative
pluggable VMs with certain desirable properties such as
platform-specific optimization (Christian, are you listening? :-).

I think the most challenging part might be defining an API for passing 
in the set of supported object types and operations.  E.g. the
EXEC_STMT opcode needs to be be implemented in a way that allows
"exec" to be absent from the language.  Perhaps an __exec__ function
(analogous to __import__) is the way to go.  The set of built-in
functions should also be passed in, so that e.g. one can easily leave
out open(), eval() and comppile(), complex(), long(), float(), etc.

I think it would be ideal if no #ifdefs were needed to remove features
(at least not in the VM code proper).  Fortunately, the VM doesn't
really know about many object types -- frames, fuctions, methods,
classes, ints, strings, dictionaries, tuples, tracebacks, that may be
all it knows.  (Lists?)

Gotta run,

--Guido van Rossum (home page: http://www.python.org/~guido/)