Support Python versions with trailing +

[charliermarsh]

It was reported that a locally-built Python with 3.11.4+ errors out in our version parser:

https://gist.github.com/jsbueno/be1797cfe654c69245ddbea78e0360ff

[BurntSushi]

The Local Version Identifiers section of the Version Specifiers spec seems to suggest that a local label needs to be non-empty, but it doesn't seem to come out and say it explicitly. With that said, the regex for parsing version numbers does unambiguously require a non-empty local version segment if a + is present.

So at least with respect to the spec, it seems like the version number here is invalid. Is there any particular reason why 3.11.4+ is being used? If it's just a mistake, then perhaps that should be fixed instead.

But if this is a widespread or common practice, then perhaps there isn't too much harm in making our version parser slightly more flexible. I think the point here though would be to decide what the semantics of 3.11.4+ are. Is the version identical to 3.11.4? And in particular, if someone gave us a 3.11.4+ version and we spit 3.11.4 back out at some point, would that be an issue? The question might seem strange, but it's the difference between a "version without a local segment" and a "version with an empty local segment." (The current representation of a Version doesn't distinguish between those cases.)

[hauntsaninja]

I think the Python version isn't governed by PEP 440.

3.11.4+ is if you build off of random CPython commit. I think it comes from e.g. https://github.com/python/cpython/blob/c08c0679055d96c0397cf128bf7cc8134538b36a/Include/patchlevel.h#L26

Should be fine to treat it as 3.11.4

[zanieb]

They seem semantically different; I would treat 3.11.4+ as fulfilling versions that are not pinned. It's rare that we request e.g. ==3.11 or ==3.11.4

[charliermarsh]

What's the issue with treating this as equivalent to parsing 3.11.4?

[edgarrmondragon]

I second @hauntsaninja. The + is usually added to Python builds that are built off the main branch rather than a tag:

>>> import pprint
>>> from packaging.markers import default_environment
>>> pprint.pprint(default_environment())
{'implementation_name': 'cpython',
 'implementation_version': '3.13.0a3',
 'os_name': 'posix',
 'platform_machine': 'arm64',
 'platform_python_implementation': 'CPython',
 'platform_release': '23.4.0',
 'platform_system': 'Darwin',
 'platform_version': 'Darwin Kernel Version 23.4.0: Wed Feb  7 23:21:07 PST '
                     '2024; root:xnu-10063.100.637.501.2~2/RELEASE_ARM64_T8112',
 'python_full_version': '3.13.0a3+',
 'python_version': '3.13',
 'sys_platform': 'darwin'}

[charliermarsh]

Makes sense. I'd also be open to just stripping a trailing + for those fields specifically... @BurntSushi, what do you think?

[zanieb]

They're different versions — the + has meaning. Similar to 1.0.0rcbeing different from 1.0.0. I don't think treating them as distinct versions would cause any problems for our usages of Python versions though. If we treat them as different you could e.g. require a local version by requesting 3.13.0+, but if you request 3.13 it should work fine even if 3.13.0+ is what we find.

[konstin]

python_full_version needs to be a PEP 440 compliant version, otherwise environment markers break (PEP 508 environment marker comparisons). Depending on your interpretation of PEP 508, we would fall back to stringly comparisons for python_full_version where '3.9.0' is lower than '3.11.4+'.

There's an upstream cpython bug: python/cpython#99968