[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Steve Dower added the comment: Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils. If this issue does not relate to distutils, please remove the component and reopen it. If

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Michael Felt added the comment: Back again - I understood a lot less then, maybe more now.. iirc, get_platform() asin sysconfig.get_platform() and distutils.util.get_platform() are suppposed to return a suitable PEP425 tag that identifies the ABI of the running interpreter - eg.g, 32-bit

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Sam Ferencik added the comment: Michael, Thanks for reopening this. You say you're using "64-bit hardware", but what bitness is your OS and the Python interpreter? If you read my original issue description, I only had this issue with 32-bit Python on a 64-bit Linux system (on 64-bit

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Michael Felt added the comment: FYI: This is 'actual' as I am working on an implementation of a cloud-init distro for AIX and it is very difficult to figure out the correct approach for a replacement value for os.uname[4] - when comparing with "Linux" logic I was thinking of using

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Michael Felt added the comment: There are so many places where there are references to where 32-bit and 64-bit are referred to - and, in particular, the value of os.uname()[4] For the discussion I went back to 32-bit Python on AIX A) michael@x071:[/data/prj/python/archive/Python-2.7.3]python

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Changes by Paul Morelle : -- nosy: +madprog ___ Python tracker ___ ___ Python-bugs-list

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Michael Felt added the comment: FYI: build as 64-bit (and shall only build as 64-bit from now I expect) and the output works as: == aixtools.python:aixtools.python.man.en_US:2.7.11.0::I:C:N:man pages0::

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Michael Felt added the comment: If you need assistance (re: AIX), just ask. However, I am guessing you have enough to move forward. -- ___ Python tracker

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Sam Ferencik added the comment: Thanks for the analysis. I agree with you. If there's much push-back, maybe we could introduce an alternative interface, i.e. let get_platform() do its thing, deprecate it, and introduce something like get_interpreter_platform(). --

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Michael Felt added the comment: while reading to learn... FYI: AIX does not return even a hint of the underlying platform (assumption is probably 64-bit) - but the value of the interpreter is anyone's guess root@x064:[/data/prj/aixtools/python/python-2.7.10]python Python 2.7.10 (default, Mar

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Dima Tisnek added the comment: beep! -- nosy: +Dima.Tisnek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18987 ___ ___ Python-bugs-list mailing

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Changes by Jason R. Coombs jar...@jaraco.com: -- nosy: +jason.coombs ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18987 ___ ___ Python-bugs-list

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

David Jones added the comment: Has there been any progress made on fixing this? I ran into this trying to install numpy via pip, 32-bit python installation on 64-bit Centos 6.4. It get's the compile flags right, but not the linker: C compiler: gcc -pthread -fno-strict-aliasing -g -O2 -m32

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Changes by Gregory P. Smith g...@krypto.org: -- title: distutils.utils.get_platform() for 32-bit Python on a 64-bit machine - distutils.utils.get_platform() for 32-bit Python on a 64-bit machine ___ Python tracker rep...@bugs.python.org

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Sam Ferencik added the comment: Thanks for the context. A compatibility issue here is that the value provided by get_platform() is also used outside of Distutils, in particular by pkg_resources (provided by setuptools) and by pip, in both cases to help determine whether a binary

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Sam Ferencik added the comment: Are you asking *what* distutils does? It tackles the problem completely differently on Windows, Unix, and OS X. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18987

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Antoine Pitrou added the comment: Are you asking *what* distutils does? Yup :-) I'm not a distutils maintainer, so I hardly know how it does things internally. It tackles the problem completely differently on Windows, Unix, and OS X. Ah... but does it compute the result by itself or simply

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Éric Araujo added the comment: FTR the Mac OS code does some normalization: http://hg.python.org/cpython/file/bda5a87df1c8/Lib/_osx_support.py#l473 Code for linux just returns the value from uname, as Same said: http://hg.python.org/cpython/file/bda5a87df1c8/Lib/distutils/util.py#l75

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Antoine Pitrou added the comment: On Unix, specifically, the return value is heavily based on os.uname(). Ouch. Then I'm afraid this is a probably a won't fix :-/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18987

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Sam Ferencik added the comment: It's very hacky on all of Windows, Unix, and OS X. That's why I don't feel confident to propose a solution. On Unix, specifically, the return value is heavily based on os.uname(). It seems that the maintainers of OS X have started with the same but then chose

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Sam Ferencik added the comment: Well, the maintainers of Mac OS didn't consider it a won't fix - and have this working properly. I don't see why we couldn't try to copy what they did. Actually, I think the impact of changing this for 32-bit Python on 64-bit Linux should be quite small, no?

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Antoine Pitrou added the comment: Well, the maintainers of Mac OS didn't consider it a won't fix - and have this working properly. I don't see why we couldn't try to copy what they did. Ah, ok. Then a patch would be welcome :-) Actually, I think the impact of changing this for 32-bit

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Ned Deily added the comment: A compatibility issue here is that the value provided by get_platform() is also used outside of Distutils, in particular by pkg_resources (provided by setuptools) and by pip, in both cases to help determine whether a binary distribution of an extension module is

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Antoine Pitrou added the comment: Hello, To discover a 32-bit interpreter running on a 64-bit system, we could use platform.architecture(), which returns platform.architecture() ('32bit', 'ELF') Just use (sys.maxsize 2**32). What then, though? How do you turn '32bit' to

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Sam Ferencik added the comment: Unfortunately, I don't have a patch. Some thoughts: To discover a 32-bit interpreter running on a 64-bit system, we could use platform.architecture(), which returns platform.architecture() ('32bit', 'ELF') What then, though? How do you turn '32bit' to

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18987 ___

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

New submission from Sam Ferencik: distutils.util.get_platform() semantically differs on (a) Windows and OS X, and on (b) Linux. Windows/OS X: the return value is derived from the architecture of the *interpreter*, hence for 32-bit Python running on a 64-bit system, get_platform() =

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com: -- nosy: +jkloth ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18987 ___ ___

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

Antoine Pitrou added the comment: Do you want to upload a patch? -- nosy: +pitrou versions: +Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18987 ___