On Wed, 14 Apr 2021 at 13:28, Victor Stinner <vstin...@python.org> wrote:
> There are two main use cases for versions:
>
> * Display them to the user
> * Compare versions to check if one is newer, older or the same
>
> I dislike using strings for comparison. You need to use
> packaging.version for that:
> https://packaging.pypa.io/en/latest/version.html
Agreed, programmatic use should really conform to PEP 440 versioning,
as implemented in packaging.version, if it's to align with existing
packaging standards (which currently focus on *project* versions
rather than package versions, but the distinction is not something we
should be making a big deal of).
> Many C libraries provide the version as a number of as 3 numbers
> (major, minor, micro). In its C API, Python provides all of them:
>
> * PY_VERSION_HEX: single number
> * (PY_MAJOR_VERSION, PY_MINOR_VERSION, PY_MICRO_VERSION,
> PY_RELEASE_LEVEL, PY_RELEASE_SERIAL): as 5 numbers
> * PY_VERSION: string
>
> In my Python projects, I like to provide the version as a tuple which
> can be used directly for comparison: version_a <= version_b. Example:
>
> VERSION = (2, 2, 1)
> __version__ = '.'.join(map(str, VERSION))
>
> The tuple might contain strings like "beta" or "rc", as soon as
> comparison makes sense ;-) Sadly, such tuple is no standardized. Which
> part is the major version? How to format it as a string?
>
> Good luck with trying to standardize that ;-)
Agreed. We should stick to PEP 440 format strings, and not try to
dictate other formats like (named) tuples.
But does the PEP want to cover programmatic use *at all*? It would be
possible to define __version__ as "a human-readable string in PEP 440
format" and note that any use other than for display to a person is
outside the scope of the PEP. That's closer in spirit to the 13-year
old version we currently have, but it does miss an opportunity as we
now do have a standard version class ("standard" in the sense of "a
packaging standard", but not "in the stdlib").
Paul
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/5LFCLXIPXF3PO6PZ5ZLS7TD2OE4U35OD/
Code of Conduct: http://python.org/psf/codeofconduct/
