That's right. No one writes 2to3 but for python 3.6 -> 3.7. The js people do. If we got into it we could have wheel tags for that sort of thing. In practice only a few classes of tags are used. On Mon, Aug 27, 2018, 22:06 Nathaniel Smith <njs@pobox.com> wrote:
I think the answer to all of these questions is "well, no-one's ever really looked that closely".
There's a theory behind the tags; they're supposed to be a reasonably expressive language for talking about Python dialect compatibility, Python C ABI compatibility, and platform ABI compatibility, respectively. But in practice so far only a small fixed set of tag combinations actually gets used, so there's plenty of room for weird stuff to accumulate in the corners where no-one looks.
I've never been able to figure out a use case for the interpreter tags in the first field ("cp36", "pp3", etc). IIUC, the theory is that they're supposed to mean "the Python code in this package is not actually portable Python, but uses an interpreter-specific dialect of the language". (This is very different from the second field, where tags like "cp36m" tell you about the required C ABI -- that one is obviously super useful.) I guess if you had a package that like, absolutely depended on GC being refcount-based, you could use a cp3 tag to indicate that, or if you had a pure-Python, python 2 package, that required 'dict' to be ordered, maybe that's 'pp2-none-any'? But this never seems to actually happen in practice. It seems like an idea that sounded plausible early on, and then never got fleshed out or revisited.
The distutils folks have never sat down to seriously think about non-CPython implementations, where the language version and the implementation version are separate things.
The pypy folks have never sat down to seriously think about API/ABI stability. Generally at the Python dialect level they try to match a given version of (C)Python, and at the ABI level every new release is a new ABI.
My guess is you shouldn't spend too much effort on trying to slavishly reproduce pip's logic, and that if you wanted to go clean up pip's logic (and maybe extract it into a reusable library?) then the devs would be perfectly happy that someone was doing it...
-n
And to help in getting a reply, here is the trimmed-down results for CPython 3.7 to compare against:
[('cp37', 'cp37m', 'macosx_10_13_x86_64'), … ('cp37', 'abi3', 'macosx_10_13_x86_64'), … ('cp37', 'none', 'macosx_10_13_x86_64'), … ('cp36', 'abi3', 'macosx_10_13_x86_64'), … ('cp35', 'abi3', 'macosx_10_13_x86_64'), … ('cp34', 'abi3', 'macosx_10_13_x86_64'), … ('cp33', 'abi3', 'macosx_10_13_x86_64'), … ('cp32', 'abi3', 'macosx_10_13_x86_64'), … ('py3', 'none', 'macosx_10_13_x86_64'), … ('cp37', 'none', 'any'), ('cp3', 'none', 'any'), ('py37', 'none', 'any'), ('py3', 'none', 'any'), ('py36', 'none', 'any'), ('py35', 'none', 'any'), ('py34', 'none', 'any'), ('py33', 'none', 'any'), ('py32', 'none', 'any'), ('py31', 'none', 'any'), ('py30', 'none', 'any')]
So, it re-iterate the questions:
What is ('pp3', 'none', 'any') supposed to represent for PyPy3? Since the version of the interpreter is PyPy3 6.0 the lack of major version number seems like a bug more than a purposeful interpreter version (and there's only a single project -- cliquet -- that has a wheel that's compatible with that tag triple and it's not even for their latest release). Why does CPython have (*, 'none', 'any') from the version of the interpreter down to Python 3.0 plus generically Python 3 while PyPy3 only gets generic Python 3? Why isn't (*, 'none', platform) listed from Python 3.7 to 3.0 for either CPython or PyPy3? I understand not iterating through all versions when an ABI is involved (without knowing exactly which versions are compatible
On Mon, Aug 27, 2018 at 6:28 PM, Brett Cannon <brett@python.org> wrote: like
abi3), but this triple seems safe to iterate through as a fallback just as much as (*, 'none', 'any'). Maybe because it's too ambiguous to know how important such a fallback would be between e.g. ('py36', 'none', 'macosx_10_13_x86_64') and ('py37', 'none', 'any'), and so why bother when the older version triples are there just for a safety net to have at least some chance of a match? I still think ('py360', 'none', 'any') is a bug. ;)
P.S.: The ('py3', 'none', 'macosx_10_13_x86_64') triple being between e.g. ('pp360', 'none', 'macosx_10_13_x86_64') and ('pp360', 'none', 'any') is really messing with my head and making the code to generate supported triples a bit less elegant. ;)
On Sat, 25 Aug 2018 at 15:03 Brett Cannon <brett@python.org> wrote:
I noticed that for PyPy3, the tag triples considered compatible were (roughly; trimmed out the long list of macOS versions):
[('pp360', 'pypy3_60', 'macosx_10_13_x86_64'), ('pp360', 'none', 'macosx_10_13_x86_64'), ('py3', 'none', 'macosx_10_13_x86_64'), ('pp360', 'none', 'any'), ('pp3', 'none', 'any'), ('py360', 'none', 'any'), ('py3', 'none', 'any')]
Now the first question I have is about ('pp3', 'none', 'any'). Is this meant to be a generic thing for any interpreter of the interpreter implementation and major version, or is this special to CPython and
PyPy3?
Question two is why isn't there a ('py35', 'none', 'any') or ('py34', 'none', 'any') and older to py30 after py3 like there is for CPython?
Seems
like if they are just source then they should be compatible as much as CPython.
Question three is why isn't there a ('py35', 'none', 'macosx_10_13_x86_64') for PyPy3 or CPython 3.7? I can't figure out what a Python- and platform-specific wheel but agnostic to API wouldn't ever work?
And I'm assuming ('py360', 'none', 'any'), isn't legitimate since that makes no sense. ;)
-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/D...
-- Nathaniel J. Smith -- https://vorpus.org -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/7...