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

On Mon, Aug 27, 2018 at 6:28 PM, Brett Cannon <brett@python.org> wrote:
> 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 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/D7H47XWWDMOIUWODELQU27TGTC5KL6WY/
>



--
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/7UIOAUJCDVAVIGYJKPZQC7DXRNJHAGX7/