Re: Three clarification questions about PEP 425 and PyPy3

Daniel Holth <[email protected]>
Newsgroups gmane.comp.python.distutils.devel
Message-ID <CAG8k2+6w1F+KgrrH9UGOiCEV29kFthMUL3isDCoTm4gzfLDuHw@mail.gmail.com>
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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 -- [email protected]
> > To unsubscribe send an email to [email protected]
> > https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
> > Message archived at
> >
> https://mail.python.org/mm3/archives/list/[email protected]/message/D7H47XWWDMOIUWODELQU27TGTC5KL6WY/
> >
>
>
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> --
> Distutils-SIG mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
> Message archived at
> https://mail.python.org/mm3/archives/list/[email protected]/message/7UIOAUJCDVAVIGYJKPZQC7DXRNJHAGX7/
>

--
Distutils-SIG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at https://mail.python.org/mm3/archives/list/[email protected]/message/NAZ4QZ7H6QDUZ3J37W3FCGSFOW7YAF5N/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.