Python 2.0 and Stackless

Christian Tismer tismer at appliedbiometrics.com
Mon Aug 7 07:07:17 EDT 2000


Toby Dickenson wrote:
> 
> "Jeff Petkau" <jpet at eskimo.com> wrote:
> 
> >Here's one way to look at it:
> >
> >For normal Python programs (that don't use stackless or uthreads),
> >the *only* effect of the stackless patch is to make Python faster
> >and more crash-resistant (since you can't overflow the C stack).
> >So it's a complete win, no downside.
> >
> >For programs that want to use stackless or uthreads, it allows
> >you to do things that you just *can't do* otherwise. Uthreads is
> >amazingly wonderful for simulations, or as a plug-in scripting
> >language for games. So it's still a complete win.
> 
> That dicotomy isnt quite the whole truth.
> 
> In a post-stackless interpreter all library code has to be aware of
> the implications of stacklessness, unless it can be sure that it will
> never be used in a stackless program.

This is not true, resp. not a problem.

> Consider this "naive" function
> 
> def m(y):
>    x()
>    try:
>       y()
>    finally:
>       z()
> 
> Today I can be sure that a call to z is always preceeded by a single
> call to x. Stacklessness makes that assumption false.

With stackless alone, you cannot change the order of
execution in any way. You need an extensionmodule that
allows such modifications. Admittedly, continuationmodule
allows you to create any messy control flow, this is not
its intent. Instead, you will not use it directly, but
via generator/iterator/coroutine/whatever implementations
which are built upon it. And they will behave correctly.

Continuations should be hidden from normal users, and if
you change the behavior of the "naive" function, then
it is up to you. I'm not even yet convinced that these
functions should be made public at all.

Anyway, stacklessness does not make that assumption false
in the first place. It only enables extension writers
to do so, and they shouldn't abuse this.
Nobody should use it in a way that makes changes to
any library function necessary.
(besides whrandom which needs to be made thread-safe anyway)

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com




More information about the Python-list mailing list