Ben Finney schrieb:
Eric Smith
writes: Ben Finney wrote:
That is, you want me to propose an example version string X. I'm asking for you to tell me corresponding examples of version strings W and Y where:
W < X < Y
since the comparison semantics are what we're discussing here.
W = 3.3.0 Y = 3.3.1
If you're going to suggest 3.3.0.99 or some such
Yes. Or any version string that would obviously fall between the two.
A specific version comparison scheme will never be obvious to all people at the same time. However we can provide one that is obvious to *most*, and it is not the one you're pushing.
I think that won't work. It's important that code sees that as 3.3.1.<something>. I've seen code that fails when the pre-release versions have a different MAJOR.MINOR.MICRO than the final version.
It's exactly that kind of code that I don't feel needs to be accommodated. It's clearly causing ambiguities and contortions, and now we talk about needing Python-specific version comparison algorithms in order to automate the comparison.
The need for pre/post-release versions is hardly Python-specific. It is used by a large fraction of developers in some way or other.
Why is this worth the trouble, when the standard could simply describe obvious-to-everyone version comparison semantics that are far easier for everyone to get right?
Very true. Surely, it will be obvious to everyone that 3.1alpha1 is a version greater than 3.1. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.