Python 2.0 and Stackless

[Robin Becker]

In article <398C06BD.4AA6C6A0 at inrialpes.fr>, Vladimir Marangozov
<Vladimir.Marangozov at inrialpes.fr> writes
...
>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.

my half pint says that the stack constrains to a single ordering.
stackless doesn't demand that you use the advantages.

>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!
>

I have a multi threaded python app can I tell which thread is to be
executed next at the language level. If I can't then surely we're in the
same boat as stackless. At the C level stackless/non-stackless are both
deterministic at present.

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

Allegedly we can only serialise apps easily which don't make use of
continuations/stackless features. That has no implications for
stackless.

>
>There are plenty of application domains where the above scenario is
>needed: thread migration in distributed systems, fault-tolerancy in
>databases, etc.
>
>So, beware <wink>.
>
>
>> Christian has done an amazing piece of work, and he's gotten much
>> praise from the community.
>
>Indeed. Nobody is against it. Some of us are conservative, though,
>and would like to weight the pros and cons before adopting a core
>feature. We've agreed that PEPs are the way to do it, because they
>summarize the issue with all pros & cons, helping people to emit
>opinions. This hasn't been done for Stackless. Do you volunteer to
>PEP it? Conservativeness is sometimes due to lack of detailed
>information, so a Stackless PEP mey well change popular beliefs
>on both sides.
>

so PEP for stackless please C Tismer.
-- 
Robin Becker