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/)