Python 2.0 and Stackless

Vladimir Marangozov Vladimir.Marangozov at inrialpes.fr
Sat Aug 5 08:21:17 EDT 2000


Hey, Just, let's talk facts!


Just van Rossum wrote:
> 
> [Jeremy]
> > It is a conservative response.
> 
> Jeremy, have you ever *looked* at stackless? ...

Can't speak for Jeremy, but I did. In detail.


[Just]
> ... No, you can't load a Java class in CPython, and yes,
> "import continuation" fails under JPython. So what?

This is a fact.


> > [Jeremy, about PEP-ing Stackless]
> 
> That's completely unfair. Stackless has been around *much* longer than
> those silly PEPs.

A fact of life (modulo 'silly PEPs').


[Just, about compatibility]
> The stackless API is 100% b/w compatible.

A fact, as long as we discuss the current API.


[Just again]
> 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. But it is also a fact that by removing the stack you lose its
benefits. So full (functional) compatibility is *not* there.

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.

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

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.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252



More information about the Python-list mailing list