On May 31, 2004, at 3:33 PM, Martin v. Löwis wrote: > Bob Ippolito wrote: >> Although I don't particularly agree with that, because Stackless >> functionality could be turned on and off with a platform dependent >> configure flag (like threads or unicode)... Is there a canonical >> list of CPU architectures and platforms that Python officially >> supports? > > No - although there is a list of platforms, that Python *doesn't* > support (PEP 11). Python is written in C, so it should work on any > system that supports ISO C, although many functions won't be available > if the system doesn't support POSIX. > > As for turning of things: yes, unicode can be turned off, but not > because the platform doesn't support it - rather because the > administrator doesn't like unicode. Threads are turned off on operating > systems that don't provide threads, and there is nothing that Python > could do about it. > > Stackless' support for platforms is different: it includes assembler > code, so you have to write bits of assembler code for each architecure > (and perhaps for each system on a single architecture, or even each > assembler on each system). I don't see how including a little bit of per-architecture-calling-convention assembler code is much different than depending on pthreads (or some other platform dependent thing) being present. There is also potentially a platform neutral way of doing it (see below). > [In addition, the approach taken by Stackless 3.0 is probably > questionable: for example, it may be that C++ exception handling > stops working in Stackless.] I'm not quite sure you are up to date on how Stackless 3.0 works. The assembly code is only there to facilitate "hard switching", which is only required to do tasklet switching in the face of some C extension that doesn't know about Stackless. The vast majority of tasklet switches use the "soft switching" mechanism, which just means that the code they use is capable of going into non-recursive mode. All pure Python code and almost all code built-in to Python goes through "soft switching", which is implemented in pure C with no stack tricks or anything. Stackless would still be a very useful addition to Python even when "hard switching" is not available. Alternatively, Armin believes that Stackless "hard switching" can actually be implemented in mostly-platform-neutral C (either by setjmp/longjmp or alloca hacks, I forget which) and has a prototype implementation in the Stackless CVS repository (though it is not integrated with Stackless itself). It might also be possible to coerce something like libffi into doing what we need it to do. I'm not sure how well "hard switching" would play with an operating system that is very protective of its stack, like OpenBSD or future versions of Windows, though. I'm also not sure how it could "break C++ exception handling" in scenarios where it wouldn't be broken anyway. I'd like to see a test of that that passes under regular Python but fails in Stackless for this. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/python-dev/attachments/20040531/e89b3b0e/smime.bin
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