[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 y

[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 eve

[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 hardware)

[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 platform.pl

[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 P

[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 mailing list Unsubscribe: https://mail.python

[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:: aixtools.python:aixtools.python.rte:2.7.11.0::I:C:N:bu

[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

Changes by Jason R. Coombs : -- stage: -> needs patch versions: +Python 3.5 -Python 3.3 ___ Python tracker ___ ___ Python-bugs-list m

[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http

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

Changes by Jason R. Coombs : -- nosy: +jason.coombs ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

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

Changes by Gregory P. Smith : -- 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 __

[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 -DND

[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 > distribu

[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 co

[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 Py

[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

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 to

[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 __

[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: > 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 simp

[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 ___ ___

[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'

[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' t

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

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[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 ___ ___

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

Changes by Jeremy Kloth : -- nosy: +jkloth ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

[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() = 'win32'/'m