On Sun, 10 Oct 2021 at 03:20, Finn Mason <finnjavie...@gmail.com> 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:
There is - it's defined in PEP 440. Python's packaging tools follow this specification, so if you don't conform to it your package is potentially not installable. It doesn't mandate semantic versioning - PEP 440 is also compatible with CalVer, for example. > * 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)`. You should look at the `packaging` library on PyPI, which is a complete implementation of many of the packaging standards, including PEP 440 versions. > 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)`. PEP 440 also includes standards for saying things like "== 3.6.*" or ">= 3.6". These are typically better for handling version constraints than simple tuple or string comparisons (they have well-defined semantics for pre- and post-release versions, for example). > 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.) PEP 440 covers all of these cases (and probably a lot more, as well). > 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). It is on PyPI, and is commonly used by packaging tools. Whether it's something that should be in the stdlib, I'll pass on for now - any proposal to move it into the stdlib would need to be supported by the owners of the `packaging` project. > This would be implemented in Python 3.11 or 3.12, but I'd recommend a > backport on PyPI if implemented. As I say, it already exists on PyPI, so the proposal should instead be framed in terms of moving that project into the stdlib, if that's what you feel is necessary (and the project maintainers are willing). Paul _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NPCM4VN3ALBTUR7RR7RLG3NPEFOPNGG3/ Code of Conduct: http://python.org/psf/codeofconduct/
