On Tue, Aug 28, 2018 at 11:46 AM, Brett Cannon <br...@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. > 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", 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... > 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 :-) -n -- 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/JDUMMO57S3MHWIXZYD4WQGKM2VAK4FLZ/
