Similarities between GNOME and Python versioning

Desktop
1

While preparing to update some scripts: It’s unfortunate it’s not the Python versioning scheme. As then I could import a Python module to handle this. The Python one seems closely related to this one, just that alpha beta is shown as ‘a’ and ‘b’. I might be mistaken.

2

It is very nearly the Python versioning scheme, though, and in fact it should be compatible with at least distutils.version.LooseVersion, and most likely distutils.version.StrictVersion as well. In particular, this issue raised by @fabiscafe:

Any such package management system would already have issues with Python version numbering, which uses the same basic patterns, and is documented to support the exact formatting chosen here (though it’s not the default/normalized form).

Since PEP 440:

Pre-release separators

Pre-releases should allow a .,-, or _ separator between the release segment and the pre-release segment. The normal form for this is without a separator. This allows versions such as 1.1.a1 or 1.1-a1 which would be normalized to 1.1a1. It should also allow a separator to be used between the pre-release signifier and the numeral. This allows versions such as 1.0a.1 which would be normalized to 1.0a1.

Pre-release spelling

Pre-releases allow the additional spellings of alpha, beta, c, pre, and preview for a, b, rc, rc, and rc respectively. This allows versions such as 1.1alpha1, 1.1beta2, or 1.1c3 which normalize to 1.1a1, 1.1b2, and 1.1rc3. In every case the additional spelling should be considered equivalent to their normal forms.

Implicit pre-release number

Pre releases allow omitting the numeral in which case it is implicitly assumed to be 0. The normal form for this is to include the 0 explicitly. This allows versions such as 1.2a which is normalized to 1.2a0.

This makes e.g. 40.alpha a completely valid alternate form, which would normalize to 40a0. And Python already uses post-release bumps, i.e. Python 3.9a1 is lower than Python 3.9b0 is lower than Python 3.9rc2, and all are lower than either Python 3.9 or Python 3.9.0.

1 Like
3

I don’t see how LooseVersion will help?

>>> from distutils.version import LooseVersion
>>> LooseVersion('40.alpha') < LooseVersion('40')
False
>>> LooseVersion('40.alpha') < LooseVersion('40.0')
Traceback (most recent call last):

From the description here, 40.alpha should be before version 40. If I try 40.alpha vs 40.0 it gives a Traceback.

I read the code for the module I referenced before, it didn’t handle alpha, only a. If I check the code behind LooseVersion it’s simple as well. Some easy example code would be helpful. I rather reference something rather than writing something myself, or e.g. copying it from ftpadmin.

Note that various systems incorporated the Python versioning scheme. So nowadays that method is pretty easy. But I don’t see the bit where I it handles ‘alpha’ as well.

4

Found it. There’s a packaging module:

>>> from packaging.version import Version, parse
>>> Version('40.alpha')
<Version('40a0')>
>>> parse('40.alpha') < parse('40')
True
>>> parse('40.alpha') < parse('40.0')
True
>>> parse('40.alpha') < parse('40.beta')
True
>>> parse('40.rc1') < parse('40')
True
1 Like
5

Aha! Great find, because yeah I too am surprised (since you pointed it out) how wide the gap is between what’s documented in PEP 440 and what’s actually implemented in distutils.version. LooseVersion seems even dumber than StrictVersion when it comes to alpha/beta/etc. releases, e.g.

>>> from distutils.version import StrictVersion as SV, LooseVersion as LV
>>> SV('3.5.7a1') < SV('3.5.7')
True
>>> LV('3.5.7a1') < LV('3.5.7')
False
>>> SV('40.0a1') < SV('40.0')
True
>>> LV('40.0a1') < LV('40.0')
False

And, of course, StrictVersion won’t even accept 40 or 40a0 as version numbers, because it requires at least major.minor.

6

I too am surprised (since you pointed it out) how wide the gap is between what’s documented in PEP 440 and what’s actually implemented in distutils.version. LooseVersion

PEP 440 is from 2013. distutils.version.StrictVersion and LooseVersion are both from 1998 and could not have been changed due to backwards-compatibility concerns. (There was one time Python developers tried to drop backwards compatibility, and the users complained loudly for a decade and a half.)

This doesn’t help people who are not deeply familiar with Python packaging history, but it should at least explain the state of affairs.

7

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.