IMO, please do merge it, but I will say again that I think it is very much short of this discussion (ignoring the thoughts on mid-/longterm improvements). It would be nice if there was even a semi-authoritative place to discourage it even when it is 100% correct conceptually such as in the case for NumPy. The documentation could be that.
+1 to what @seberg suggests.
I’d also add that this there should be a way to have the upper bounds in metadata at some point - either in this field, or in a new to-be-created field. This metadata is definitely relevant, just not for the current state of pip, Poetry & co that are unable to solve for Python version. When working towards metadata that is actually representative of the package itself, rather than only how it’s built for distribution on PyPI, this is a current gap / pain point. Having downstream distro packagers derive the upper bound empirically from the cp3xx wheels that are present on PyPI for a given release rather than looking at a metadata file is not great. And with PyBIs or another such solution for packaged Python releases, it may be relevant for PyPI-focused tools in the future as well.
3 Likes