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?"
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4