| msg243223 - (view) |
Author: Matthias Klose (doko) *  |
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 --. 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 - - 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 . Also it would be nice to see the ABITAGS used for windows as well. |
|
|
| msg243227 - (view) |
Author: Steve Dower (steve.dower) * |
Date: 2015-05-14 22:33 |
| Currently we have the form -, 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) * |
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 ". On OS X for get_platform(), we provide a string of the form: "macosx"--<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 |
|
|
| msg243234 - (view) |
Author: Matthias Klose (doko) * |
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) * |
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) * |
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 http://ms-iot.github.io/content/Downloads.htm - it's a bit tricky to get to the dl from there though...) |
|
|
| msg243265 - (view) |
Author: Paul Moore (paul.moore) * |
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...) |
|
|