Guido van Rossum wrote:
Anything that can be supported by a pure extension module is fair game IMO. But it was my understanding that Stackless requires changes to the VM.
As Armin has shown, it is possible to do the hard switching approach as a pure extension module. But that's the opposite of what I want. I want a supportive core without the need to fiddle with C stacks. That needs VM changes. Cheating and supplying a different VM as an extension module is probably no option? :-)
Hey, that's what Stackless already does. Why is that approach suddenly not good enough any more?
I didn't say that. I was just suggesting that if people had specific features of Stackless that they wanted to see in CPython, that it would be best for them to write a PEP specifically addressing the desired feature(s), rather than asking "why isn't CPython stackless?"
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. It is most probably possible to implement soft-switchign in Jython. No idea what you mean by arbitrary exceptions (I never had that) or what's wrong with semantics. 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.
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. 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".
ciao - chris