On Wed, 29 Aug 2018 at 01:56 Nathaniel Smith <
njs@pobox.com> wrote:
On Tue, Aug 28, 2018 at 11:46 AM, Brett Cannon <brett@python.org> wrote:
> py36
>
> py36-none-% but not py36-none-any: 2 (example)
>
> py3
>
> py3-none-% but not py3-none-any: 142 (example)
Oh right, and these ones are totally sensible: this is the correct tag
for a project that ships some vendored shared libraries, and accesses
them using cffi's ABI mode, or through ctypes: it cares about the
CPU/OS ABI, but doesn't use the Python C ABI.
Yep. I was just surprised that py37-none-% wasn't being emitted as acceptable since that technically makes sense.
> In the end I think you can view the interpreter tag as representing a
> namespace for the ABI tag.
The ABI tags are all designed to be unique though, without
namespacing. Also, in theory the semantics are slightly different,
because cp36 means "3.6 or higher",
Do you happen to know where that's specified? I knew cp36m was locked to 3.6, but I don't think I was aware of cp36 meaning it was forwards-compatible from 3.6 (I just think of abi3 having that kind of forwards-compatibility, plus pip isn't even checking for cp37-cp37-%). Most of my knowledge of what the ABI tags mean has come from code introspection as I don't' know if the exact meaning for CPython is written down anywhere.
And there's a single project that matches cp36-cp36-%.whl. :)
while cp36m means "exactly 3.6,
with --enable-pymalloc but without --enable-debug". A "cp35-cp36m"
wheel is technically possible, though of course not very useful in
practice...
I think figuring out what makes sense in terms of compatibility will be the toughest bit. E.g. for Python 3.7, pip will check for py37-none-any down to py30-none-any as well as py3-none-any. With python_requires in metadata well as the py3 interpreter tag, I'm not sure if it still makes sense to enumerate all the way down to py30, especially when Python doesn't follow strict semver. Maybe for Python 3.7 py37, py3, and py36 makes the most sense by assuming code is warning-free in Python 3.6 and so should be relatively safe to use in 3.7 with warnings? Otherwise I wouldn't expect e.g. 3.5 code to work in 3.7 since there's new keywords that old code might break on.
> That's exactly what I'm in the process of doing. :) My goal is to have a
> library that tools will drop their internal copies of pep425tags for so
> there's a standardized PEP 425 implementation. I just wanted to make sure
> that before I write any more code that I knew what needed to be handled for
> backwards-compatibility versus what is a historical accident or was a guess
> at what the future might need when the PEP was written.
>
> Anyway, I will give this a think and try to come up with a reasonable
> algorithm for generating the sequence of supported tags based on a specific
> tag and Python version and then code that up into a library (at least I will
> definitely have something to work on at the dev sprints :) .
Cool, see you there :-)
Yes, a week and a half away!
-Brett
-n
--
Nathaniel J. Smith -- https://vorpus.org