Looking at http://docs.python.org/lib/module-os.html, I find the following: name The name of the operating system dependent module imported. The following names have currently been registered: 'posix', 'nt', 'mac', 'os2', 'ce', 'java', 'riscos'. This implies that there's a registry somewhere? Bill
Great idea! Sounds like a PEP (informational, probably) would be good idea.
On Tue, Mar 18, 2008 at 4:59 PM, Bill Janssen <janssen@parc.com> wrote:
I don't think this is bike-shedding.
The debate about "AMD64" vs. "amd64" vs. "x86_64" reminded me that I've been bit more and more frequently by bits of platform-specific knowledge scattered around the standard library. The latest is the code in distutils.unixccompiler that tries to figure out what flags to send to the linker in order to add a dynamic library path lookup to a shared library.
There are lots of different ways of figuring out which platform is being used, and they're all over the place. The code in distutils.unixccompiler uses "sys.platform[:6]", and looks for "darwin"; the code in urllib.py uses "os.name", and expects it to be "mac", but later looks for "sys.platform == 'darwin'; posixfile believes that platforms come with version numbers ("linux2", "aix4"); pydoc and tarfile have tests for "sys.platform == 'mac'". tempfile looks at os.sys.platform *and* os.name.
Could well be that all of these are correct (I believe that "mac", for instance, refers to the generations of the Mac OS before OS X). But it means that when someone tries to update "Python" to a new major version release for, say, OS X, it's really easy to miss things. And the fact that the platform version is sometimes included and sometimes not is also problematic; darwin9 is different from darwin8 in some important aspects.
It would be nice to
(a) come up with a list of standard platform symbols, (b) put those symbols somewhere in the documentation, (c) have one way of discovering them, via sys or os or platform or whichever module, (d) add a standard way of discovering the platform version, and (e) stamp out all the other ways that have crept in over the years.
Bill _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)