At 11:49 AM -0400 06-08-2000, Barry A. Warsaw wrote: >It's okay if there are some peripheral modules that are available to >CPython but not JPython (include Python .NET here too), and vice >versa. That'll just be the nature of things. But whatever basic >language features Stackless allows one to do /from Python/ must be >documented. The things stackless offers are no different from: - os.open() - os.popen() - os.system() - os.fork() - threading (!!!) These things are all doable /from Python/, yet their non-portability seems hardly an issue for the Python Standard Library. >That's the only way we'll be able to one of these things: > >- support the feature a different way in a different implementation >- agree that the feature is part of the Python language definition, > but possibly not (yet) supported by all implementations. Honest (but possibly stupid) question: are extension modules part of the language definition? >- define the feature as implementation dependent (so people writing > portable code know to avoid those features). It's an optional extension module, so this should be obvious. (As it happens, it depends on a new and improved implementation of ceval.c, but this is really beside the point.) Just PS: thanks to everybody who kept CC-ing me in this thread; it's much appreciated as I'm not on python-dev.
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