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 <n...@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 <br...@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 <br...@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-le...@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-le...@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/
>
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@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/NAZ4QZ7H6QDUZ3J37W3FCGSFOW7YAF5N/
