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
On Wed, Mar 19, 2008 at 02:05:37AM +0900, mhammond@keypoint.com.au wrote:
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).
Debian uses 'amd64', it seems they chose this after a survey of what existing systems used what names, and the consensus came out in favour of amd64. http://lists.debian.org/debian-ctte/2004/06/msg00041.html
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, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 20 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611
M.-A. Lemburg schrieb:
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).
This is the output of a 32-bit Python running on "Windows XP Professional x64 Edition, Version 2003, Service Pack 2": C:\Python24>ver Microsoft Windows [Version 5.2.3790] C:\Python24>python Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
import sys sys.getwindowsversion() (5, 2, 3790, 2, 'Service Pack 2')
Thomas
On 2008-03-20 13:42, Thomas Heller wrote:
M.-A. Lemburg schrieb:
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).
This is the output of a 32-bit Python running on "Windows XP Professional x64 Edition, Version 2003, Service Pack 2":
C:\Python24>ver
Microsoft Windows [Version 5.2.3790]
C:\Python24>python Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
import sys sys.getwindowsversion() (5, 2, 3790, 2, 'Service Pack 2')
Thank you ! Anyone with a 64bit Vista ? Or even better: a page documenting what to expect from the system call behind the sys.getwindowsversion() API ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 20 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611
On 2008-03-20 13:55, M.-A. Lemburg wrote:
On 2008-03-20 13:42, Thomas Heller wrote:
M.-A. Lemburg schrieb:
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). This is the output of a 32-bit Python running on "Windows XP Professional x64 Edition, Version 2003, Service Pack 2":
C:\Python24>ver
Microsoft Windows [Version 5.2.3790]
C:\Python24>python Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
import sys sys.getwindowsversion() (5, 2, 3790, 2, 'Service Pack 2')
Thank you !
Anyone with a 64bit Vista ?
Or even better: a page documenting what to expect from the system call behind the sys.getwindowsversion() API ?
FYI: I added winreg and sys.getwindowsversion() support in r61674. platform.machine() and .processor() will now use the environment variables PROCESSOR_ARCHITECTURE and PROCESSOR_IDENTIFIER where available (should work on Windows XP and later). According to http://support.microsoft.com/kb/888731 platform.machine() will return "AMD64", so I guess the "x64" string is just a marketing name for 64-bit platforms on Windows and the underlying system uses "AMD64" as machine type name. For x86 processors, you'll now get "x86" on Windows XP and later. For Itanium processors, you should get "IA64" according to this WOW64 page: http://msdn2.microsoft.com/en-us/library/aa384274(VS.85).aspx -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 20 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611
participants (7)
-
Bill Janssen -
Christian Heimes -
Jon Ribbens -
M.-A. Lemburg -
mhammond＠keypoint.com.au -
Thomas Heller -
Trent Nelson