...

...

...

...

"AMK" == Andrew M Kuchling writes:

AMK> Fredrik Lundh writes: >> Define version_info to be a tuple (major, minor, micro, level); >> level is a string "a2", "b1", "c1", or '' for a final release. >> maybe level should be chosen so that version_info for a final >> release is larger than version_info for the corresponding beta >> ? AMK> 'a2' < 'b1' < 'c1' < 'final' Another reason I don't like the strings: 'b9' > 'b10' :( I can imagine a remote possibility of more than 9 pre-releases (counting from 1), but not more than 15 (since PY_RELEASE_SERIAL has to fit in 4 bits), so at the very least, make that string 'a02', 'a03', etc. -Barry

...

...

...

...

"Fred" == Fred L Drake, Jr writes:

Fred> Doesn't this further damage the human readability of the Fred> value? A little, but it's a fine compromise between the various constraints. Another way you could structure that tuple is to split the PY_RELEASE_LEVEL and the PY_RELEASE_SERIAL. Make the former even more readable if you want, and make the latter a real int. Thus Python 1.6a2 would have a sys.version_info() of (1, 6, 0, 'alpha', 2), e.g. the form is: (major, minor, micro, level, serial) You can't use 'gamma' though because then you break comparability. Maybe use 'candidate' instead? Sigh. Fred> I thought that was an important reason to break it Fred> up from sys.hexversion. (Note also that you're not just Fred> saying more than 9 pre-releases, but more than 9 at any one Fred> of alpha, beta, or release candidate stages. 1-9 at each Fred> stage is already 27 pre-release packages.) Well, Guido hisself must have thought that there was a remote possibility of more than 9 releases at a particular level, otherwise he'd have jammed PY_RELEASE_SERIAL in 3 bits. I mean, there's no other possible explanation for his choices is there?! :) -Barry

BAW> Thus Python 1.6a2 would have a sys.version_info() of (1, 6, 0, BAW> 'alpha', 2), e.g. the form is: BAW> (major, minor, micro, level, serial) BAW> You can't use 'gamma' though because then you break comparability. Yeah, you can. Don't use 'final'. Use 'omega'... ;-) Skip

I can imagine a remote possibility of more than 9 pre-releases (counting from 1), but not more than 15 (since PY_RELEASE_SERIAL has to fit in 4 bits)

or rather, "I can imagine a remote possibility of more than 5 pre-releases (counting from 1), but not more than 9 (since PY_RELEASE_SERIAL has to fit in a single decimal digit"? in the very unlikely case that I'm wrong, feel free to break the glass and install the following patch: #define PY_RELEASE_LEVEL_DESPAIR 0xD #define PY_RELEASE_LEVEL_EXTRAMUNDANE 0xE #define PY_RELEASE_LEVEL_FINAL 0xF /* Serial should be 0 here */ </F>

Fredrik Lundh writes:

...

maybe level should be chosen so that version_info for a final release is larger than version_info for the corresponding beta ?

I thought about that, but didn't like it; should it perhaps be 'final'? If the purpose is to simply make it increase monotonically like sys.hexversion, why not just use sys.hexversion?

readability? the sys.hexversion stuff isn't exactly obvious:

...

...

dir(sys) ... 'hexversion' ... sys.hexversion 17170594

eh? is that version 1.71, or what? "final" is okay, I think. better than "f0", at least ;-) </F>

...

...

...

...

"Fred" == Fred L Drake, Jr writes:

Fred> I didn't say hexversion was pretty or that anyone liked Fred> it! Writing the docs, version_info is a *lot* easier to Fred> explain. So is it easier to explain that the empty string means a final release or that 'final' means a final release? :) -Barry

Barry A. Warsaw writes:

And I think (but am not 100% positive) that once a final release comes out, Guido stops incrementing the PY_RELEASE_SERIAL's and instead starts incrementing PY_MICRO_VERSION. If that's not the case, then it complicates things a bit.

patchlevel.h includes a comment that indicates serial should be 0 for final releases.

So is it easier to explain that the empty string means a final release or that 'final' means a final release? :)

I think it's the same; either is a special value. The only significant advantage of 'final' is the monotonicity provided by 'final'. I'm not convinced that it's otherwise any better. It also means to create a formatter version number from this that you need to special-case the last item in sys.version_info. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

Barry A. Warsaw writes:

Yes, absolutely. Please don't break the comparability of version_info or the connection with the patchversion.h macros.

So I'm the only person here today who prefers the release level of a final version to be '' instead of 'final'? Or did I miss all the messages of enthusiastic support for '' from my screaming fans? -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

Barry A. Warsaw writes:

I've blocked those messages at your mta, so you would't be fooled into doing the wrong thing. I'll repost them to you, but only after you

I don't mind that, just don't stop the groupies! ;) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives