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.

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.

@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:

"macosx"-<ABI>-<UNIVERSAL_CPU_ARCHS>

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

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).

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?

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 http://ms-iot.github.io/content/Downloads.htm - it's a bit tricky to get to the dl from there though...)

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...)