future of Python: Stackless, Standard -> fragmentation ?

[Will Ware]

Thomas Weholt (thomas at cintra.no) wrote:
> ... could Python be fragmented in the future due to "distros" like
> (ActivePython), Stackless Python  and JPython ...
> ... Is the difference between the different
> implementations any reason for concern at all?

I can't speak for ActivePython, but I know a little bit about the stories
with JPython and Stackless. JPython replaces Python's virtual machine,
normally written in C and part of the source code for Python, with Java's
virtual machine. Stackless Python is a variant with a modified virtual
machine, where information that was previously kept on the C stack is
moved to a separate data structure, with the consequence that threads of
execution can be separated from one another, allowing for pickling
(storing the thread away to be continued later) and microthreading (running
several little threads concurrently, each a few opcodes at a time).

Alas, Stackless Python and JPython cannot be merged. The reason for this
is that the Java virtual machine cannot be modified to become stackless in
the sense that CPython's virtual machine can be. Technically it may be
possible to write a modified JVM (there is at least one open-source JVM
out there somewhere), but a forked JVM would never come into common usage,
and any benefit of running Python on a standardized VM would be lost.

Were it not for the irreconcilable differences between Stackless and
JPython, Stackless might have made it into the 2.0 release. The people who
make these decisions (Guido and company at BeOpen) are well aware of these
issues and many more, and have thought them through in much greater detail
than you or I have done. So I'll reiterate the Python community refrain
of "in Guido we trust".

-- 
# - - - - - - - - - - - - - - - - - - - - - - - -
# Resistance is futile. Capacitance is efficacious.
# Will Ware	email:    wware @ world.std.com