This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: please align the platform tag for windows
Type: Stage:
Components: Windows Versions: Python 3.5
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: doko, ned.deily, paul.moore, steve.dower, tim.golden, zach.ware
Priority: normal Keywords: patch

Created on 2015-05-14 22:18 by doko, last changed 2022-04-11 14:58 by admin.

File name Uploaded Description Edit
windows-tags.diff doko, 2015-05-14 23:25 review
Messages (7)
msg243223 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2015-05-14 22:18
Steve, I'd like to align the platform tag across platforms to "something" uniform.  For POSIX systems we currently use the form <base cpu>-<os>-<abi>.  This is derived from the autoconf host definition. Currently the windows builds use "win32", "win_ia64", "win_arm", "win_amd64". Would you consider (in descending priority):

 - to replace the _ with a -. The autoconf host definition use
   the dash as a separator, while the _ is used inside the
   single fields.
 - to change the order to <base cpu>-<os>
 - to use the cpu names i386, x86_64, ia64 and arm (and maybe
   for the future aarch64).

It maybe doesn't make sense to change these where these tags exist in released versions, but it would be nice to have some common scheme used for the major platforms.

Note that Darwin uses this too, but chooses to only encode the <os>.

Also it would be nice to see the ABITAGS used for windows as well.
msg243227 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-05-14 22:33
Currently we have the form <Python version>-<os>, and the _ is within the OS field.

There are no released final versions with these tags, so we can go ahead and change them however we like.

Not sure exactly what you mean by "the ABITAGS" - Windows has no ABITAGS to my knowledge.

Since I assume they're going to remain hard-coded into PC/pyconfig.h, I'm quite happy for anyone to go in and change them. While I started off thinking they were a great idea, I'm not so enamoured anymore and don't really mind how they look.
msg243232 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2015-05-14 23:19
@doko, are you referring to the results of {sysconfig,distutils.util}.get_platform()? What effect would this have on third-party packages that currently support multiple versions of Python?

Also, if get_platform() is meant, I don't understand the comment "Darwin uses this too, but chooses to only encode the <os>".  On OS X for get_platform(), we provide a string of the form:


where ABI is derived from the minimum OS X level deployment target

and UNIVERSAL_CPU_ARCHS is a name that identifies the set of CPU architectures included in the fat binaries for this build. 

Common examples:
   macosx-10.5-fat -> runs on 10.5 or later systems with Intel-32 or PPC-32 support

   macosx-10.6-intel -> runs on 10.6 or later systems with Intel-32 (i386) or Intel-64 (x86_64) support

   macosx-10.10-x86_64 -> runs on 10.10 or later with only Intel-64 support
msg243234 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2015-05-14 23:25
no, I mean something like the attached patch.

get_platform() is dependent on the environment, not the platform that python was built for (e.g. it tells you x86_64 when running a 32bit python) on a 64bit kernel).
msg243235 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2015-05-14 23:29
OK, but I still don't understand your comment about OS X.  get_platform() on OS X in general returns info about the platform build environment (e.g. the implied set of all OS versions and CPU archs supported), not about the specific machine environment this instance is executing in.  Is there something you think should be changed?
msg243236 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-05-14 23:51
The patch makes it a little clearer, but I'd prefer the OS to be "win32" rather than just "win". Win32 is the name of the API set that Python is built against - it's as close to an ABI for the operating system as we ever get.

(For contrast, WinRT is the only other API set, and it's not entirely compatible with Win32 even though there is some overlap. Python currently doesn't support WinRT except in the custom builds used for PTVS for IoT at - it's a bit tricky to get to the dl from there though...)
msg243265 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2015-05-15 12:42
So just to be clear - this proposal would *only* affect the tagged filename used for loading ".pyd" files? (And in practice, the untagged form is normally used for Windows .pyd files anyway...)
Date User Action Args
2022-04-11 14:58:16adminsetgithub: 68386
2015-05-15 12:42:49paul.mooresetnosy: + paul.moore
messages: + msg243265
2015-05-14 23:51:00steve.dowersetmessages: + msg243236
2015-05-14 23:29:20ned.deilysetmessages: + msg243235
2015-05-14 23:25:18dokosetfiles: + windows-tags.diff
keywords: + patch
messages: + msg243234
2015-05-14 23:19:57ned.deilysetmessages: + msg243232
2015-05-14 22:33:47steve.dowersetmessages: + msg243227
2015-05-14 22:18:21dokocreate