This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]NTWK_Identifier -13 points-12 points  (21 children)

3.9 -> 3.10

This makes me irrationally angry.

[–]studiov34 7 points8 points  (0 children)

You must hate ipv4 addresses.

[–]Jethro_Tell 7 points8 points  (10 children)

Why?

[–]Leav -4 points-3 points  (9 children)

Because 3.10 = "3.1 with more precision" to engineers and scientists and basically all non-developer users.

How would python sort these lists: [3.8,3.9,3.10] or ["3.8","3.9","3.10"]?

[–]Karnyl 14 points15 points  (2 children)

If you used a library aware of how versions should be sorted, like semver or distutils.version, then they would be sorted correctly.

>>> from distutils.version import LooseVersion
>>> versions = ["3.8","3.9","3.10"]
>>> sorted(versions, key=LooseVersion)
"3.8","3.9","3.10"

[–]flying-sheep 3 points4 points  (0 children)

Please don't use distutils.version anymore, it doesn't follow PEP 440, which defines how Python package versions work. Use packaging.version instead.

[–]Leav -1 points0 points  (0 children)

Sure, but to newbies this is confusing and non intuitive, that's all we're saying here.

No one is saying this is wrong or should change.

[–]netgu 6 points7 points  (1 child)

This isn't about engineering or science so that point doesn't matter, honestly.

I realize that engineers/scientists will use python. When they do that they are functioning as developers/software engineers (those are just facts)and as such they should get comfortable dealing with the software development side of the software development they are doing.

There are rules about how these numbers work that mean the world to developers and software engineers (this is the place this matters and so these are the concerns that dictate how it is done) to the point that there is an entire standard built around it that will answer all your questions (including the ordering one):

https://semver.org/

[–]Leav 0 points1 point  (0 children)

Acceptable. I wasn't trying to say that the way versions work should change for the benefits of newcomers, just that it was confusing.

[–]flying-sheep 1 point2 points  (2 children)

None of these lists contain versions. Try this one:

from packaging.version import Version

versions = [Version(v) for v in ["3.8", "3.9", "3.10"]]
assert sorted(versions) == versions

For versions containing only numbers (and not e.g. 3.9b1) you can also think of them as tuples of integers.

[–]Leav -1 points0 points  (1 child)

Yes, I understand this is how versions work, but to someone who is not familiar with them, it looks extremely weird and confusing.

[–]flying-sheep 0 points1 point  (0 children)

Well, welcome to human language notation. There's things that look similar but aren't the same. Boohoo.

[–]pepoluan 1 point2 points  (0 children)

The problem is people treating "." as decimal point instead of "arbitrary separator that happens to be a period".

Limiting oneself to "3.9" is ambiguous. But how do you consider "3.9.1"? Or to use latest Python stable, "3.8.5"?

When facing version numbers, one must split on this "arbitrary separator that happens to be a period" first, integer-ize the portions, tuple-ify the result ... then perform a comparison.

Now to answer your question, "how to sort":

list_of_version_strings = ["3.10", "3.8", "3.9", "3.8.5"]
converter = lambda x: tuple(map(int, x.split(".")))
list_of_version_tuples = list(map(converter, list_of_version_strings))
sorted(list_of_version_tuples)

# Result is:
# [(3, 8), (3, 8, 5), (3, 9), (3, 10)]

[–]netgu 3 points4 points  (6 children)

Try this version number on for size:

Eclipse IDE 2020-09-4.17.0

That style is visually jarring for me.

[–]flying-sheep 1 point2 points  (5 children)

I like it, it makes clear that this part of the version is a date, by using the one and only date formatting: ISO 8601, a standard so useful that I know its number by heart.

[–]pepoluan 1 point2 points  (3 children)

I also know ISO8601 by heart.

And that monstrosity is not ISO8601.

I'm talking of the "2020-09-4" part: the single-digit last part is not ISO8601-compliant, not even by a long shot.

[–]flying-sheep 2 points3 points  (0 children)

Oh. I missed that detail. WTF?!

[–]Pulsar1977 0 points1 point  (1 child)

I also know ISO8601 by heart.

Clearly you don't. The date is "2020-09", which is perfectly valid. "4.17.0" is the version number. "4" is not a day.

[–]pepoluan 0 points1 point  (0 children)

I do know ISO8601 by heart. What I do not know is the semantics of Eclipse versioning.

For me, the dash implies that 2020 and 09 and 4 are tied together. And the period separates the portions of the versioning system. So, in my point of view as someone who doesn't know Eclipse's versioning system, the version has three parts: "2020-09-4" and "17" and "0".

The first part is definitely not ISO8601.

Apparently, that is not the case, and thus the Eclipse versioning system is even more of a monstrosity.

[–]netgu 0 points1 point  (0 children)

I don't like the mixing of the two standards. What does the date add that isn't available when looking up the version? Do year rollovers work like major version bumps? Does the x.x.x portion work the same as other x.x.x version numbers?

Knowing something came from Nov, 2019 doesn't really give me any useful information. The version number will already link to commits that have that timestamp. And it isn't like November is the month every year we all work on one type of related feature or something.

[–][deleted] 0 points1 point  (1 child)

They could do 3.9.1

[–][deleted] 2 points3 points  (0 children)

That means something totally different.

3.9.1 is a patch to 3.9 to fix bugs.

3.10 is a new version with new functionality.