sysconfig.get_platform returns wrong value when Python 32b is running under Windows 64b

[jcrmatos]

BPO	35896
Nosy	@pfmoore, @tjguk, @pmp-p, @zware, @eryksun, @zooba, @jcrmatos

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2019-02-05.15:58:58.856>
created_at = <Date 2019-02-04.21:33:45.579>
labels = ['invalid', '3.7', '3.8', 'OS-windows']
title = 'sysconfig.get_platform returns wrong value when Python 32b is running under Windows 64b'
updated_at = <Date 2019-02-06.16:08:49.437>
user = 'https://github.com/jcrmatos'

bugs.python.org fields:

activity = <Date 2019-02-06.16:08:49.437>
actor = 'steve.dower'
assignee = 'none'
closed = True
closed_date = <Date 2019-02-05.15:58:58.856>
closer = 'steve.dower'
components = ['Windows']
creation = <Date 2019-02-04.21:33:45.579>
creator = 'jcrmatos'
dependencies = []
files = []
hgrepos = []
issue_num = 35896
keywords = []
message_count = 10.0
messages = ['334841', '334842', '334844', '334849', '334873', '334876', '334878', '334883', '334935', '334947']
nosy_count = 7.0
nosy_names = ['paul.moore', 'tim.golden', 'pmpp', 'zach.ware', 'eryksun', 'steve.dower', 'jcrmatos']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue35896'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5', 'Python 3.6', 'Python 3.7', 'Python 3.8']

[jcrmatos]

sysconfig.get_platform returns wrong value when Python 32b is running under Windows 64b.
It should return win-amd64 and returns win32.

[pmp-p]

i think that platform is called SysWoW64 and is more or less win32.
https://en.wikipedia.org/wiki/WoW64

[jcrmatos]

That's the name of the subsystem, not the platform.
Check the article you indicated
"In computing on Microsoft platforms, SysWoW64 (Windows 32-bit on Windows 64-bit) is a subsystem..."

[pmp-p]

from what I remember it's a platform-vm where you can't call (host) 64bits abi or access (host) 64 bits registry. registry calls are overlaid under a "WoW64" branch in host registry. Nothing like aarch64 or Darwin

[zooba]

This is intentional. The "platform" here represents the Python platform (for figuring out whether native modules are compatible), and since it's the 32-bit build of Python it should specify the 32-bit platform.

To find out information about the machine you are running on, look at the platform module: https://docs.python.org/3/library/platform.html

[jcrmatos]

Then what is the difference between sysconfig.get_platform and sys.platform? When should we use one or the other?

Maybe changing sys.platform to 'win' instead of 'win32', like was done with 'linux' in Python 3.3 (changed from 'linux2' and 'linux3') would be a step in standardization and simplification.

Another one is sys.platform and sysconfig.platform return 'win32' and os.name returns 'nt'. Can't it be changed (in Python 4) to 'win', maybe with a deprecation warning starting in 3.8?

[pmp-p]

what is the difference

sys.platform is defined by code path taken while compiling. it is hardcoded and really represents the os abi used of a *supported* platform, it is to be trusted.

while sysconfig.get_platform() try to guess from various sources with more or less success.

changing sys.platform
on windows there are a number of different abi ( eg msvc (32/64 supported) / cygwin / mingw / midipix .... ) and one should expect sys.platform to point to the correct one.

The maintainers ( like steve.dower ) help choose carrefully those codes and ensure they will always work, so i think you have been answered.

[zooba]

sys.platform is defined by code path taken while compiling. it is hardcoded and really represents the os abi used of a *supported* platform

Correct, though the examples I'd give are Win32 vs. WinRT vs. Cygwin, which are fundamentally different API surfaces for interacting with the operating system.

sys.platform is win32 whenever Python is built against the Win32 API. sysconfig.get_platform is win32 when packages need to be built for 32-bit Windows. It's unfortunate that they were chosen to be the same, but that's long in the past, and I don't think the confusion is worth the confusion that would occur if it changed.

os.name is also odd, and honestly I'd rather it just went away completely. I'd like the module to be called "posix" everywhere, since that's the API it exposes (it's an emulation layer on non-POSIX platforms), and checks should use sys.platform. Or at worst, "_os" instead of having an importable "nt" module. But for better or worse, that's how Python is designed, and until there's a serious project to redesign aspects at this level we aren't going to see any change.

[eryksun]

Correct, though the examples I'd give are Win32 vs. WinRT vs. Cygwin,
which are fundamentally different API surfaces for interacting with
the operating system.

Cygwin and MSYS are presented as more than APIs; they're separate platforms. sys.platform is 'cygwin' or 'msys', and os.name is 'posix'.

The Windows platform name is "win32". If we could change it, I'd prefer "windows". The C API is the "Windows API" or WINAPI. It used to be called Win32, which is still the popular name. The ABI for 32-bit x86 (Intel Architecture) is "win32". If we could change it, I'd prefer "win-ia32" to parallel "win-amd64".

os.name is also odd, and honestly I'd rather it just went away
completely. I'd like the module to be called "posix" everywhere,
since that's the API it exposes (it's an emulation layer on
non-POSIX platforms), and checks should use sys.platform.

os is too entrenched to be renamed. But I'd like it if nt (posixmodule.c) were renamed windows_posix (or win32_posix) -- since it has nothing to do with the NT API. We would need to move the Windows-only functions to a "windows" (or "win32") platform module. This includes _getdiskusage, _getfinalpathname, _getfullpathname, _getvolumepathname, _isdir, and startfile. They have no place in a POSIX module.

[zooba]

This includes _getdiskusage, _getfinalpathname, _getfullpathname, _getvolumepathname, _isdir, and startfile. They have no place in a POSIX module.

Except for startfile, I disagree. They are all there to help implement POSIX compatibility, and as private APIs, there's no better place to put them.

In any case, this issue is closed for now, pending a discussion on python-dev. If anyone feel strongly about making changes, it'll need to start with a post on the mailing list.