[Python-Dev] Stackless Python

[Guido van Rossum]

> That needs VM changes. Cheating and supplying a different VM
> as an extension module is probably no option? :-)

Not unless you can write it in Java or C# as well.  C-only hacks are
not welcome.

> > I think the bar should be raised pretty high for Stackless, given
> > the various objections that have been raised against it (x86-only
> > code, no Jython support, arbitrary exceptions, murky semantics, to
> > name a few).
> 
> Huh? There is support for 8 or more platforms, and I'm not addressing
> the assembly parts.

OK, that's good news.

> It is most probably possible to implement soft-switchign in Jython.

That's a rather vague statement; I'd like to hear from Samuele about
that.

> No idea what you mean by arbitrary exceptions (I never had that)

I meant exceptions to the general rules.  Like, you can't depend on
tasklet switching when you use one of these extensions, or one of
these built-ins, or ...

> or what's wrong with semantics.

Last time we (PythonLabs) looked at this, there were many murky rules
that were difficult to explain except by looking at the accidents of
the implementation.  I take it you have removed all that?

> On the latter: Well, this is a pure interface issue. I don't say
> that everybody must love tasklets, there are other approaches and
> interfaces possible.  But they all rely on the non-recursive
> interpreter core, and that's the point, IMHO.

Is it really just tasklets that the users want?  Then maybe we should
focus on adding tasklets to Jython too, so as to understand the
requirements and limitations of the approach better outside the
context of a C implementation.  (Jython must remain 100% pure Java.)

> > Together, the answer as to "why" should be pretty clean by now.
> 
> If you understand the question like "why is current Stackless
> not included", that's true.

That started the thread, yes.

> I understood it more like the more advanced question "why does
> Python still block itself from lightweight threading by keping state
> on the C stack".

IMO mostly because Python wants to be friendly to extensions written
in C or C++, including those that frequently call back into Python.

--Guido van Rossum (home page: http://www.python.org/~guido/)