David Ascher wrote: >... > I'm not denying that. It's just that there are lots of things which fall > into that category, like (to take a pointed example =), os.fork(). We > don't have a --with-fork configure flag. We expose to the Python > programmer all of the underlying OS that is 'wrapped' as long as it's > reasonably portable. I think that most unices + win32 is a reasonable > approximation of 'reasonably portable'. And in fact, this change might > motivate someone with Mac fervor to explore adding Python support of Mac > threads. Agreed. Python isn't a least-common-demoninator language. It tries to make things easy for people. Why should we kill all platforms because of a lack on one? Having threads by default will make a lot of things much simpler (in terms of knowing the default platform). Can't tell you how many times I curse to find that the default RedHat distribution (as of 5.x) did not use threads, even though they are well-supported on Linux. And about stuff creeping into the distribution: gee... does that mean that SocketServer doesn't work on the Mac? Threads *and* fork are not available on Python/Mac, so all you would get is a single-threaded server. icky. I can't see how adding threads to other platforms will *hurt* the Macintosh platform... it can only help others. About the only reason that I can see to *not* make them the default is the slight speed loss. But that seems a bit bogus, as the interpreter loop doesn't spend *that* much time mucking with the interp_lock to allow thread switches. There have also been some real good suggestions for making it take near-zero time until you actually create that second thread. Cheers, -g -- Greg Stein, http://www.lyra.org/
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