[Python-Dev] Trial balloon: microthreads library in stdlib

[Talin]

Richard Tew wrote:
> See "A Bit Of History"
> http://svn.python.org/view/stackless/trunk/Stackless/readme.txt

I admit that I haven't given Stackless more than a cursory look over, 
but it seems to me that the real source of its complexity is because its 
trying to add a fundamental architectural feature to Python without 
completely re-writing it.

Writing a purely stateless, "stack-less" language interpreter is not 
that hard, as long as you are willing to drink the KoolAid from the very 
start - in other words, you don't allow any function call interfaces 
which are not continuable. This does make writing C extension functions 
a little bit harder than before, as you now have to explicitly manage 
all of your local variables instead of just pushing them on the hardware 
stack.

(Actually, for "simple" C subroutines that don't call any other 
interpreted functions, you can write it like a normal C functions just 
as you always have.)

The nightmare comes when you try to glue all this onto an existing 
language interpreter, which wasn't written from the start with these 
principles in mind - AND which doesn't want to suffer the impact of a 
large number of global changes. To be honest, I can't even imagine how 
you would do such a thing, and the fact that Stackless has done it is 
quite impressive to me.

Now, I'm very interested in Stackless, but, as you say, like many people 
I've tended to shy away from using a fork.

Now, the question I would like to ask the Stackless people is: Rather 
than thinking about wholesale integration of Stackless into Python 
mainline, what would make it easier to maintain the Stackless fork? In 
other words, what would you change about the current Python (it could be 
a global change) that would make your lives easier?

What I'd like to see is for the Stackless people to come up with a list 
of design principles which they would like to see the implementation of 
Python conform to. Things like "All C functions should conform to such 
and such calling convention".

What I am getting at is that rather that doing heroic efforts to add 
stackless-ness to the current Python code base without changing it, 
instead define a migration path which allows Python to eventually 
acquire the characteristics of a stackless implementation. The idea is 
to gradually shrink the actual Stackless patches to the point where they 
become small enough that a direct patch becomes uncontroversial.

-- Talin