Paul Moore
Here's an alternative suggestion:
* Versions are treated as dot-separated tuples * Comparison is component-by-component, exactly as Python tuples compare
Agreed so far (unsurprisingly, because so far it matches the algorithm I outlined).
* Components must have the form [a-z]*[0-9]+([a-z][0-9]+)? (ie, optional leading alphas, an integer, and an optional "letter-integer" suffix) * Call the 3 parts "prefix" ([a-z]*), "number" ([0-9]+), "suffix" ([a-z][0-9]+) * Components compare as follows: - Components with differing prefixes are incomparable[1]. Otherwise, ignore the prefix. - Within this, sort by the number part (as a number, not as text) - Within this, components with a suffix sort BEFORE those without, in the obvious letter-then-number order.
That's a little messy
More than a little. That's not something I'd expect people to keep in their head without needing to look at the specification frequently; or, worse, make a guess and often get it wrong.
but I think it follows people's intuition,
I think it's far from obvious that this represents an intuitive comparison scheme. It's yet another set of special cases for certain tokens, as far as I can see; which leads us back to the point that as soon as we get into those, there's far less consensus about how they should work.
allows for most of the variations people want, and most importantly (to my mind) isolates the complexity to how *components* sort against each other (the high-level rule is "like tuples", which is simple).
Yes, I've no disagreement about version strings being sorted like tuples at the component level. I don't see how you claim that as a distinguishing characteristic of this suggestion.
[1] Note that I see the "prefix" as cosmetic. I would expect real projects to use a fixed prefix on a component-by-component basis - 1.2.r34567 or 1.2.dev5 or whatever, but never a mix of 1.2.3, 1.2.r1234 and 1.2.dev5.
Why not? We've already had people talking about a mix of ‘a123’, ‘post123’, ‘b123’, ‘r123’, ‘dev123’, etc. I think any version comparison scheme needs to allow a definite statement to be made about the sequencing of *any* possible version strings, with only the answers {equal, less-than, greater-than} possible.
Hence, I have said that mixed prefixes are incomparable. If this causes an outcry,
The cry is a simple “What does that mean I should do with two version strings that are incomparable?”.
the following rule could be used instead:
- Components with a prefix sort before components without, in alphabetic order of prefix
but in my view it adds unnecessary complexity (and hence I'd like to see real-world, justified use cases).
Actually, that seems *simpler*. It's such a simplification, in fact, that it makes this rule redundant: it's covered already by the existing rules (AFAICT). You've essentially got components within components, but some components sort differently from others by non-obvious rules, and worst of all some components “are incomparable”; what does *that* mean when I need to compare them for sequence? I think “can keep the whole specification in one's head easily” is an important criterion for any version comparison scheme that we promote for the standard library. People should be able to learn it once, then be able to look at any two version strings in the future and quickly know what sequence Python will put them in, without going back to the specification again for special cases and differing comparison rules. -- \ “I have never imputed to Nature a purpose or a goal, or | `\ anything that could be understood as anthropomorphic.” —Albert | _o__) Einstein, unsent letter, 1955 | Ben Finney