I was surprised that max_version determines from where we read the Python versions.

The idea is that you would have to guess the upper bound ( https://discuss.python.org/t/requires-python-upper-limits/12663), so one method (classifiers) doesn't have an upper bound, and the other requires it. Though it could be split if you have good ideas for names.

Makes sense. Another approach would be to always look at Trove classifiers first, and fall back to requires_python if no classifiers are found. The max_version parameter would then just do what it says on the tin: apply an upper bound. (If it's not specified and we can't determine the upper bound from pyproject.toml, we could either bail out or apply our notion of what Python's current version is.) I don't feel strongly about this, though. Happy for this to go in 👍

That's exactly what I originally tried, actually, but then I would have had to implement filtering, and why would you ever want to filter the classifiers using this parameter? What would be more likely to happen is someone would forget to update this bound when adding the classifier. Also, having it be "auto" means you'd have to pick what to do if classifiers and requires-python didn't match.

Hi!
Would that work with Programming Language :: Python :: 3.13t.
Or is this a bad classifiers?

That's not a valid classifier. All valid classifiers are here: https://pypi.org/classifiers/

And the plan would be to add something like pypa/trove-classifiers#195, not a 3.13t classifier.

You can add to this list or process it, though. Including adding PyPy, etc.