There is a Version type in the packaging package that imjments the “official” versioning scheme for PyPI packages.

Should it be in the stdlib? Maybe, I think it has used casss beyond pip and friends.

I’ve actually written my own more limited  version (wink) myself for versioning a data model. I would probably have used one from the stdlib if it were there. And maybe I would have used the one in packaging if I had know about it when I wrote the code.


On Sat, Oct 9, 2021 at 7:18 PM Finn Mason <> wrote:
Hello all,

I was thinking about the following idioms:

__version__ = "1.0"

import sys
if sys.version_info < (3, 6):
    # Yell at the user

I feel like there could be a better way to define versions. There's no real standard way to specify versions in Python, other than "use semantic versioning." This can cause problems such as:

* Uncertainty of the type of the version (commence the pattern matching! Or `if... elif` statements if that's your thing)
* No real way to specify an alpha, beta, pre, or post version number in a tuple of ints, e.g. `(2, 1, 0, "post0")` doesn't really work.

I propose a new `Version` type, a standard way to define versions. The signature would look something like `Version(major: int, minor: int = 0, patch: Optional[int] = None, alpha: Optional[int] = None, beta: Optional[int] = None, pre: Optional[int] = None, post: Optional[int] = None)`.

To maintain backwards compatibility, comparisons such as `Version(1, 2) == (1, 2)` and `Version(1, 2) == "1.2"` will return `True`. `str(Version(1, 2))` will return `"1.2"` (to clarify, if `patch` were 0 instead of None, it would return `"1.2.0"`). There will be an `as_tuple()` method to give the version number as a tuple (maybe named tuple?), e.g. `Version(1, 2).as_tuple()` will return `(1, 2)`.

A problem is that not all versioning systems are covered by this proposal. For example, I've done some programming in C#, and many C# programs use a four number system instead of the three number system usually used in Python code, i.e. major.minor.patch.bugfix instead of major.minor.patch. (This may not seem very different, but it often is.)

Where to place this type is an open question. I honestly have no good ideas. This could just be implemented as a PyPI package, but there may not be a point in adding a whole dependency to use a semantic type that other people probably aren't using (which wouldn't be the case if it were part of core Python).

This would be implemented in Python 3.11 or 3.12, but I'd recommend a backport on PyPI if implemented.

Questions? Thoughts? Suggestions to improve it?
Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct:
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython