Antoine Pitrou wrote:
Sent: Friday, December 12, 2014 1551 To: Distutils-Sig@Python.Org Subject: Re: [Distutils] PYD/SO platform tags (#22980)
On Fri, 12 Dec 2014 23:23:03 +0000 Steve Dower Steve.Dower@microsoft.com wrote:
There's a bit of discussion going on at http://bugs.python.org/issue22980
about extending SO tags to include bitness values, and I took the opportunity to look into adding platform tags for .pyd files on Windows.
There's a patch up there, but I'm interested in any thoughts or concerns people may have that I haven't considered. Distribution is likely to be most affected, and I figured distutils-sig is most likely to have people with strong opinions on the subject anyway, so I'm posting here :)
Basically, importlib.machinery.EXTENSION_SUFFIXES is all that changes. It'll
go from [".pyd"] to [".cp35-win32.pyd", ".cp3-win32.pyd", ".pyd"] (where "win32" may also be "win_amd64", "win_ia64" or "win_arm", which are the platforms that have #ifdefs in pyconfig.h).
For the record, https://www.python.org/dev/peps/pep-3149/#pep-384 suggests "abi3" as the ABI tag for the Python 3 stable ABI.
My legalistic rationale for using cp3 is that it's actually the version tag, not the ABI tag. It seemed from my reading that you'd get tags like "cp35-abi3-win32", which is not helpful because you've still specified the minor version in the tag. Either it'll work in any CPython 3.x ("cp3") or it needs a specific minor version ("cp35"), so I didn't see the value in keeping the ABI tag.
Of course, this only works because Windows doesn't use the ABI tag for anything else. Debug builds are encoded differently, and AFAICT the malloc and Unicode options are currently unnecessary and I'm not making any change to make them necessary.
I could be swayed on this point fairly easily though, if say there are other interpreters out there not compatible enough with CPython to use the cp tag but that can still use stable ABI extensions that were build assuming CPython. Or I could just drop the second tag and only have "cp35-win32.pyd" or ".pyd". We've made it this long without a specifier, so there's no real need to go overboard :)