As far as I know no one has released a compiler that turns f-strings into not-f-strings. If something like that existed, then you could have two wheels for the same software, one that had been passed through the compiler to remove f-strings and gain compatibility with older Python. If you were doing something like that then the pyXY tag becomes useful. Python-Requires is more useful for the ordinary case.
The arch-only tags are an example of something we had to add because a previously theoretical case became real.
It is a little silly but harmless to go all the way down to py30. Python 3.2 or 2.6 were perhaps the oldest Pythons bdist_wheel could ever run on (2012).

On Thu, Aug 30, 2018 at 2:01 PM Nathaniel Smith <njs@pobox.com> wrote:
On Thu, Aug 30, 2018, 08:23 Nick Coghlan <ncoghlan@gmail.com> wrote:
On Thu, 30 Aug 2018 at 09:58, Brett Cannon <brett@python.org> wrote:
> On Wed, 29 Aug 2018 at 15:54 Nathaniel Smith <njs@pobox.com> wrote:
>> This is a tricky decision. Any time a new Python comes out, some
>> existing wheels will continue to work fine, and some will be broken.
>> One goal is to avoid installing broken wheels. But, there's also
>> another consideration: if we're too conservative, then with every
>> release we create a bunch of make-work as projects have to re-roll old
>> wheels that would have worked fine, and some percentage of projects
>> won't do this (e.g. b/c they're abandoned), and we lose them forever.
>> Also, for the py3x tags in particular, if the wheel fails on py3(x+1),
>> then the sdist probably will too, so it's not like we have any useful
>> fallback.
>
> Right, but isn't that what the py3-none-any tag is meant to represent? If someone doesn't use that tag then I would take that as there is some version-specific stuff in that wheel.

The problem is that "py3-none-any" doesn't specify a *minimum*
version, so if a project starts using a new feature like f-strings,
they *have* to declare "py36-...".

That's the theory, but I think these tags are useless in practice.

If you're on py35 and pip sees a wheel with py36 as the tag, then it falls back to building from the sdist. For ABI-related tags this makes sense, because given an sdist and an appropriate compiler, you have a good chance of being able to generate wheels for some arbitrary platform, even one that the original authors never heard of. But... the python dialect tags are different. If your wheel uses f-strings, then your sdist probably does too, so all the tag does is move around the error to happen somewhere else.

To avoid this, you have to put a Python-Requires header in your metadata. It's the only thing that works for sdists. And it also works for wheels. And it's strictly more expressive than the wheel tag version (you can write arbitrary restrictions like ">= 3.5.2, != 3.6.1". Note that 3.5.2 actually is a common minimum version for lots of async libraries, because it had a breaking change in the core async/await protocols).

So I don't think there's any case where the pyXY tags are actually useful. You're always better off using Python-Requires.

-n
--
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/K72BHTS6S3JX2U7BWYVDK2EZB3ZY3VI4/