At 08:17 PM 5/31/04 -0700, Guido van Rossum wrote:
If soft-switching is portable (i.e. pure C, no assembly), and is exposed as a library module (so that Jython et al can avoid supporting it), then perhaps a PEP for adding that functionality to mainstream Python would be meaningful.
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.
I did mean *exposed* as a library module, not implemented as one. I am aware of the VM change.
And I definitely don't want people to get into a habit of writing code that relies on deep recursion that is only supported by Stackless, only to find that it doesn't work in Jython etc.
From the docs of sys.setrecursionlimit(): """The highest possible limit is platform-dependent. A user may need to set the limit higher when she has a program that requires deep recursion and a platform that supports a higher limit. This should be done with care, because a too-high limit can lead to a crash.""" Seems to me that the platform-specific nature of this is already established.
If that gets in, then the other 5% can always sneak in later via feature creep. ;) Or, more importantly (if I understand correctly), it could be separately distributed as an add-on for platforms that can support it.
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?"