make LooseVersion('1.0') == LooseVersion('1')

[Flamefire]

Remove the pitfall where missing components were filled with empty strings that are less than any other value.

The common expectation is that trailing zeroes are equal to zeroes.
I don't think there is any case where 1.0 > 1 is intended

If the trailing part is a string the current behavior is kept.

See the changed test case where "# Careful here: 1.0 > 1 !!!" can be removed now.

[akesandgren]

I bet that some stupid developer will make version 1 and then produce version 1.0 as being newer then 1...
And then @boegel will have more material for his talk...

[Flamefire]

I bet that some stupid developer will make version 1 and then produce version 1.0 as being newer then 1... And then @boegel will have more material for his talk...

Sure. But technically 1.0-alpha < 1.0 but that isn't the case for LooseVersion either (it is the reverse), and on purpose hence the "Loose".
I'd argue that us expecting version > LooseVersion("1") holds for version=1.0 and 1.0.0 is more important to meet

The documentation:

When comparing version numbers, the numeric components will be compared numerically, [...]
the rules for comparison are simple and predictable, but may not always give the results you want (for some definition of "want").

to me implies 1.0 != 1 is not as simple and predictable. But I guess that's opinionated too.
If that is disagreed on I'll drop that again, but I'd keep the other fix to the EasyConfigObj in a separate PR

[Micket]

I'm not aware of any situations where this actually has mattered, but i'm fine with the logic change.

[lexming]

I agree with the premise that 1 should always be considered at the same level as 1.0. But technically, according to PEP440, version 1 is indeed lower than 1.0. See https://peps.python.org/pep-0440/#summary-of-permitted-suffixes-and-relative-ordering

You can have development and alpha versions like 1.dev0 in between 1 and 1.0 for instance.

[Micket]

I'd just add the note that we use this not really specific for python packages but for all kinds of software packages which probably don't feel a need to follow PEP440 (but they also probably don't feel a need to follow semver or any other guides and just do whatever the heck they want)

If a develop actually make a 1 release, then follow that up with a 1.dev0 and a final 1.0 release they are just evil.

I thinking it's mostly going to be us that might use the single digit, for scenarios like

if self.version >= LooseVersion('7.0'):  # what if version is just 7?
     self.new_installation_step()
else:
     self.legacy_installation_step()

edit: uhm, i didn't think that example through, i hoped i fixed it to a maybe-realistic scenario.

[lexming]

As I said, I agree with this change. It is easier to dance around rare exotic versions than having to constantly handle 1 being different than 1.0. Just wanted to make sure that we are aware this breaks a PEP and we do this consciously.

[Flamefire]

But technically, according to PEP440, version 1 is indeed lower than 1.0. See https://peps.python.org/pep-0440/#summary-of-permitted-suffixes-and-relative-ordering

I don't read it as such. The opposite: We fix this to match the described PEP:

All release segments involved in the comparison MUST be converted to a consistent length by padding shorter segments with zeros as needed.

You can have development and alpha versions like 1.dev0 in between 1 and 1.0 for instance.

My understanding of

Within a numeric release (1.0, 2.7.3), the following suffixes are permitted and MUST be ordered as shown:

.devN, aN, bN, rcN, , .postN

is that 1.dev0 < 1. and with the above 1. == 1.0. So I'd expect 1.dev0 < 1.0 which is in the table.

Our class doesn't follow that though: Because "dev0" > "0" we have 1.dev0 > 1 and equivalently1.dev0 > 1.0. But ours is a LooseVersion, not a SemVersion anyway.

@Micket How about:
if self.version >= LooseVersion('7.0'): # what if self.version is either 7 or 7.0.0

With this change they'd all be equal, i.e. True, before the former was false, the latter true if I'm not mistaken.

[Micket]

yes I'm in favour of this change, I tried to write an example where the old behavior was undesirable. I asked the other maintainers for opinions, and it doesn't seem like people have strong opinions or vaguely in favor, so in this goes.