Python 2.0 and Stackless

[Gordon McMillan]

Vladimir Marangozov wrote:

>
>Hey, Just, let's talk facts!
>
>
>Just van Rossum wrote:

>> There are (or could/should be) additional calls for extension writers
>> and embedders that would like to take advantage of stackless features,
>> but full compatibility is *there*.
>
>An illusion <wink>.
>
>Fact is that the stack prevents you from having continuations at the C
>level. 

I think Just meant extensions playing well with Python continuations, as in 
what Christian did for map. If you want continuations at the level of the 
implementation language, I think you'd need to change implementation 
languages!

>But it is also a fact that by removing the stack you lose its
>benefits. So full (functional) compatibility is *not* there.

I'd grant you the first sentence if I thought stacks *had* any functional 
benefits over graphs. But the only benefit I know of is simplicity at the 
price of reduced functionality. After all, a stack is just a special case 
of a graph.

>Whenever you switch from a pile of execution frames (a stack) to a graph
>of frames, you lose the strict frame ordering typical for a stack.

There is still a stack. The difference is that it only holds the state of 
the execution engine, not the Python that's executing.

>One consequence is that given an execution point P, for which there's a
>corresponding frame Pf, with the advent of the stack you can figure out
>the current call path of the program. Without the stack, this is hard!
>
>This has direct consequences for people interested in serializing the
>interpreter state. Currently, if I stop the interpreter at P, I *can*
>serialize the whole interpreter state (including the objects and the
>stack of execution frames), then restore it, say on another machine, and
>resume the execution at P. Without the stack, this would be a royal pain
>to do (it is not impossible, but it is hard).

Seems to me that requests for this feature have largely been met with 
"Dream on!". One of the difficulties sited is the fact that the C-stuff on 
the stack has to be untangled from the Python stuff. OTOH, with stackless, 
it's trivial to capture the current state of the Python stuff (you can do 
that right now, you just can't persist it).

>There are plenty of application domains where the above scenario is
>needed: thread migration in distributed systems, fault-tolerancy in
>databases, etc.

Actually, the major problem in these domains is being able to rewind / undo 
I/O (or rather, the state of external resources).

- Gordon