Consistent platform name for 64bit windows (was: distutils.util.get_platform() for Windows)
I'm reviving a very old thread based on discussions with Martin at pycon.
Sent: Monday, 23 July 2007 5:12 PM Subject: Re: [Distutils] distutils.util.get_platform() for Windows
Rather than forcing everyone to read the context, allow me to summarize: On 64bit Windows versions, we need a "string" that identifies the platform, and this string should ideally be used consistently. This original thread related to the files created by distutils (eg, pywin32-210.win???64??-py2.6.exe) but it seems obvious that we should be consistent wherever Python wants to display the platform (eg, in the startup banner, in platform.py, etc).
In the old thread, there was a semi-consensus that 'x86_64' be used by distutils (and indeed, Lib/distutils/util.py in get_platform() has been changed, by me, to use this string), but the Python 'banner', for example, reports AMD64. Platform.py doesn't report much at all in this area, at least when pywin32 isn't installed, but it arguably should.
Both Martin and I prefer AMD64 as the string, for various reasons. Firstly, it is less ugly than 'x86_64', and doesn't include an '_'/'-' which might tend to confuse parsing by humans or computers. Martin also made the point that AMD invented the architecture and AMD64 is their preferred name, so we should respect that.
So, at the risk of painting a bike-shed, I'd like to propose that we adopt 'AMD64' in distutils (needs a change), platform.py (needs a change to use sys.getwindowsversion() in preference to pywin32, if possible, anyway), and the Python banner (which already uses AMD64).
Any objections? Any strong feelings that using 'AMD' will confuse people with Intel processors? Strong feelings about the parsability of the name (PJE? <wink>)? Strong feelings about the color <wink>?
Thanks,
Mark
mhammond@keypoint.com.au schrieb:
So, at the risk of painting a bike-shed, I'd like to propose that we adopt 'AMD64' in distutils (needs a change), platform.py (needs a change to use sys.getwindowsversion() in preference to pywin32, if possible, anyway), and the Python banner (which already uses AMD64).
+1 for AMD64
If we ever need names for Itanium and i386 compatible arch I propose IA64 and X86.
Christian
+1 for avoiding a bikeshed, so +1 to AMD64.
________________________________________ From: python-dev-bounces+tnelson=onresolve.com@python.org [python-dev-bounces+tnelson=onresolve.com@python.org] On Behalf Of Christian Heimes [lists@cheimes.de] Sent: 18 March 2008 13:54 To: mhammond@keypoint.com.au Cc: distutils-sig@python.org; python-dev@python.org Subject: Re: [Python-Dev] Consistent platform name for 64bit windows (was: distutils.util.get_platform() for Windows)
mhammond@keypoint.com.au schrieb:
So, at the risk of painting a bike-shed, I'd like to propose that we adopt 'AMD64' in distutils (needs a change), platform.py (needs a change to use sys.getwindowsversion() in preference to pywin32, if possible, anyway), and the Python banner (which already uses AMD64).
+1 for AMD64
If we ever need names for Itanium and i386 compatible arch I propose IA64 and X86.
Christian _______________________________________________ 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/tnelson%40onresolve.com
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
Christian Heimes wrote:
mhammond@keypoint.com.au schrieb:
So, at the risk of painting a bike-shed, I'd like to propose that we adopt 'AMD64' in distutils (needs a change), platform.py (needs a change to use sys.getwindowsversion() in preference to pywin32, if possible, anyway), and the Python banner (which already uses AMD64).
+1 for AMD64
I'm also +1 for AMD64 (or amd64).
BTW, the wikipedia entry for AMD64 points out that FreeBSD, NetBSD, OpenBSD, Debian, Ubuntu, Solaris, and the Java Development Kit all use "amd64". Though it claims that Microsoft and Sun both use 'x64' in their marketing material.
If we ever need names for Itanium and i386 compatible arch I propose IA64 and X86.
IA64 seems pretty standard so +1 on that.
But I'm -1 on the X86. It's too easy to get confused with what that means versus terms like x86-16, x86-32, and x86-64. Admittedly the first two are little used, but I have seen them once or twice. What's wrong with using i386 itself?
-- Dave
On 2008-03-18 18:05, mhammond@keypoint.com.au wrote:
I'm reviving a very old thread based on discussions with Martin at pycon.
Sent: Monday, 23 July 2007 5:12 PM Subject: Re: [Distutils] distutils.util.get_platform() for Windows
Rather than forcing everyone to read the context, allow me to summarize: On 64bit Windows versions, we need a "string" that identifies the platform, and this string should ideally be used consistently. This original thread related to the files created by distutils (eg, pywin32-210.win???64??-py2.6.exe) but it seems obvious that we should be consistent wherever Python wants to display the platform (eg, in the startup banner, in platform.py, etc).
In the old thread, there was a semi-consensus that 'x86_64' be used by distutils (and indeed, Lib/distutils/util.py in get_platform() has been changed, by me, to use this string), but the Python 'banner', for example, reports AMD64. Platform.py doesn't report much at all in this area, at least when pywin32 isn't installed, but it arguably should.
Both Martin and I prefer AMD64 as the string, for various reasons. Firstly, it is less ugly than 'x86_64', and doesn't include an '_'/'-' which might tend to confuse parsing by humans or computers. Martin also made the point that AMD invented the architecture and AMD64 is their preferred name, so we should respect that.
So, at the risk of painting a bike-shed, I'd like to propose that we adopt 'AMD64' in distutils (needs a change), platform.py (needs a change to use sys.getwindowsversion() in preference to pywin32, if possible, anyway), and the Python banner (which already uses AMD64).
Any objections? Any strong feelings that using 'AMD' will confuse people with Intel processors? Strong feelings about the parsability of the name (PJE? <wink>)? Strong feelings about the color <wink>?
Not really an object, but Microsoft itself uses the term "x64" for the 64-bit variants of their OS, e.g.
http://www.microsoft.com/windowsxp/64bit/default.mspx
Since the platform name is targeting Windows, I think we should avoid confusing Windows users more than Intel users ;-)
About the platform.py changes: if someone could provide the return values of sys.getwindowsversion() for 64bit versions of Windows XP and Vista, I could add support for it (don't have a 64bit version of Windows available to check myself).
Thanks,
participants (6)
-
Bill Janssen -
Christian Heimes -
Dave Peterson -
M.-A. Lemburg -
mhammond＠keypoint.com.au -
Trent Nelson