effigies / looseversion

A backwards/forwards-compatible fork of distutils.version.LooseVersion
Other
13 stars 1 forks source link

Python 2 support and consistent behavior #16

Closed effigies closed 1 year ago

effigies commented 1 year ago

It is unclear if this package will ever be used by Python 2 users, but it seems that the behavior in Python 2 was that str and int were comparable, so #6 and #11 indeed are bugs from the perspective of consistent behavior across Python versions.

If someone wants (and it might be me if I get bored) to add Python 2 support and tests to confirm Python 2 behavior, I would be willing to modify the code to support identical semantics in Python 3.

We could then distribute a universal wheel.

intgr commented 1 year ago

Thanks! I have no interest in adding Python 2.x support, but I think it's worth fixing it so it doesn't crash on Python 3.x at least.

The behavior on Python 2 is counterintuitive and was probably accidental. Arguably beta1 should be less than 2, but:

Python 2.7.18 (default, Oct 18 2022, 11:09:45)
>>> from distutils.version import LooseVersion
>>> LooseVersion('1.1.beta1') < '1.1.2'
False
>>> LooseVersion('1.1-beta1') < '1.1.2'
False

Both of these crash in Python 3.x right now.

intgr commented 1 year ago

So we need to decide what's the preferred ordering on Python 3.x: do we replicate the (arguably counterintuitive) logic of LooseVersion from distutils as it was for Python 2.x, or do we try to improve it.

As I understand, your preference would be to replicate the old behavior?

effigies commented 1 year ago

The behavior on Python 2 is counterintuitive and was probably accidental. Arguably beta1 should be less than 2, but:

Python 2.7.18 (default, Oct 18 2022, 11:09:45)
>>> from distutils.version import LooseVersion
>>> LooseVersion('1.1.beta1') < '1.1.2'
False
>>> LooseVersion('1.1-beta1') < '1.1.2'
False

I think the goal was to always give a result and not a parse error. The counterintuitive results are, if not a feature, a non-bug.

As I understand, your preference would be to replicate the old behavior?

Yes. I think there's room for a library of lots of version comparison schemes or to make it easy to define a custom scheme. I don't want to make this package that.

intgr commented 1 year ago

Oops, sorry, I totally forgot about this. Thanks!