[Stackless] Looking for information on meaning of "stackless"

David J. C. Beach beach at verinet.com
Mon Feb 16 21:26:37 CET 2004

On Fri, 2004-02-13 at 19:45, David Smiley wrote:
> I'm a Java programmer but with an interest in programming language in 
> general.  I was getting an overview of Python on the web when I 
> stumbled upon a link to "Stackless Python".  The stackless.com website 
> says it's a Python implementation that "does not use the C stack".  I 
> don't know enough about the C language or operating system internals to 
> understand what that means.  Can someone explain or, even better, point 
> me to where I can educate myself about such things online?  Also... 
> what benefits to a Python application will there be for running 
> stackless?  Assuming Stackless Python becomes wildly successful, would 
> there be any point in /not/ running stackless?  (i.e. are there 
> trade-offs?)


I'm generally a lurker on this list and am not actively involved in
either the development of Stackless Python, or as a user of this
implementation.  If anyone else on this list disagrees with me, you
should listen to them....

WITH THAT OUT OF THE WAY, I believe I can answer your question:

What it means that "Stackless Python" doesn't use the C stack?  The
stack is the part of memory where C stores "local" variables (those
variables stored within the body of a function), arguments passed to
other functions (during a function call) are also stored in this section
of memory.  Every time a function is called in C, a new "frame" is said
to be pushed onto the stack.  Thus, in a chain of function calls (A()
calls B() calls C()), there are separate frames on the stack for each of
these functions.

Both Python and Stackless Python are implemented in C and use the C
stack, just like any other program.  The major difference relates to how
the python interpreter behaves when a function is called in Python (i.e.
what happens when A(), B(), and C() are Python functions instead of C

In the standard Python distribution, there is at _least_ one "C"
function call for every level of Python function call.  In other words,
Python function calls end up using the C stack.  This has certain
negative effects:  It means that recursive algorithms in Python are
limited by the C stack.  It also means that it is not possible to create
logic which jumps between different levels of the stack (or involves
"multiple overlapping" stacks) in Python.  The reason for this all has
to do with the Python implementation:  The Python interpreter uses the C
stack for Python function calls.

Stackless Python takes a different approach to this.  Instead of storing
the Python stack using the C stack, Stackless Python uses heap memory,
and links the stack frames together with C pointers into a tree.  This
means that the Stackless implementation can switch between different
Python stack frames at different levels at will.  This type of
implementation makes "exotic" flow-control constructs possible, such as
microthreads, generators, and continuations.

(At this point, the astute Python programmer will ask -- Hey, aren't
generators already available in regular Python?  Yes, _Simple_
generators are, but these can only generate values from the top level of
function call, and they cannot be used as a general way to transfer
control between stack frames unless they have a direct "parent/child"
relationship...  The Stackless implementation of generators is a "full
on" approach and is much more general than that.)

I am no expert on these styles of programming, but they can be used to
make certain types of tasks much easier than they are using conventional
structured programming.  For example, microthreads are very useful for
people writing simulation code, or any other code which needs to be
multi-threaded for "sanity" reasons and not for "performance" reasons
(some server code falls into this category).  I'm sure the other members
of this list could tell you much more about the usefulness of these

Stackless Python adds some overhead (but not much), but this is not the
reason that it hasn't been included in the standard distribution of
Python.  A major reason has to do with its interaction with C
extensions.  Put simply, adding all this exotic flow-control stuff on
the Python side of things makes it very difficult to determine how to
properly interact with certain C extensions.  Python, on the other hand,
was designed to be a glue language, and so the support of existing type
extensions has always been considered a major priority.  Also, I believe
Guido is a big believer in simplicity (there's only one way to do it;
short way == right way == easiest way, etc.)  This is my very favorite
aspect of programming in Python (life's hard enough, you code shouldn't
have to be.)   I'm not sure that most Python programmers are ready for
the kinds of changes (disturbing amounts of power) that Stackless Python
can introduce (although they're getting there).  Finally, the
implementation of Stackless still seems to be under heavy revision.  It
is for these reasons, that Stackless has not yet found its way into the
standard distros of Python.  Hopefully, some day it will.


David J. C. Beach
<beach at verinet.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://www.stackless.com/pipermail/stackless/attachments/20040216/e7b7e77b/attachment.pgp>
-------------- next part --------------
Stackless mailing list
Stackless at stackless.com

More information about the Stackless mailing list