On Wed, 22 Apr 2009 11:12:22 +0200, Tarek Ziadé <ziade.tarek@gmail.com> wrote:

Hi,

We worked during Pycon on version comparisons. Distutils has one but it is a bit strict, setuptools has another one, but it's a bit heuristic.

We would like to propose the inclusion for Python 2.7 of a new version comparison algorithm, based on the discussion Fedora, Ubuntu and Python people had. The plan would be to deprecate the current one (which is not really used anyway) and provide, promote this one.

Trent Mick took the lead on this work at the end of Pycon, and worked on a prototype.

It's explained here, and there's an implementation (I've put it at the top of the page for conveniency):

http://wiki.python.org/moin/Distutils/VersionComparison

Clearly being able to parse the string representation is important, since this information will largely reside in non-Python text files. I suppose that many people will also be very comfortable with and happy about writing RationalVersion(somestring) and ">=somestring". However, it would also be great if there were a way to construct a version object out of structured data instead. Can a constructor which takes each part of the version data as a separate object be added? Jean-Paul

...

 Can a constructor which takes each part of the version data as a separate object be added?

Sounds good, I'd be in favor of making RationalVersion using explicit version bits, and having some kind of function:

str2version(somestring) -> RationalVersion instance

Or we could have: RationalVersion(...version bits...) RationalVersion.from_string(s) # this is a @classmethod

I have pushed the prototype in a bitbucket project so everyone can work it out (just join the project)

http://bitbucket.org/tarek/distutilsversion/

Thanks for putting this up. If we provide a way to construct a RationalVersion with version bits, then we need to discuss what those "version bits" look like. Currently the internal tuple data structure (`self.info`) looks like this (from verlib.py's description of the 'f' marker used to help with sort ordering, http://bitbucket.org/tarek/distutilsversion/src/cc93f5e1df3f/verlib.py#cl-16...): # A marker used in the second and third parts of the `info` tuple, for # versions that don't have those segments, to sort properly. A example # of versions in sort order ('highest' last): # 1.0b1 ((1,0), ('b',1), ('f',)) # 1.0.dev345 ((1,0), ('f',), ('dev', 345)) # 1.0 ((1,0), ('f',), ('f',)) # 1.0.post345 ((1,0), ('f',), ('post', 345)) # ^ ^ # 'f' < 'b' -------------/ | # | # 'dev' < 'f' < 'post' -----------/ # Other letters would do, bug 'f' for 'final' is kind of nice. Is this what we would want the constructor to take? RationalVersion( (1,0), ('b', 1) ) # 1.0b1 RationalVersion( (1,0), ('f',), ('post', 345) ) # 1.0.post345 It seems a little too low-level. We could allow something a little nicer: RationalVersion( (1, 0, 'b', 1) ) # 1.0b1 RationalVersion( (1, 0, 'post', 345) ) # 1.0.post345 If we did this, then we'd probably want these attributes on RationalVersion:

...

...

v = RationalVersion((1,0,'b',1)) str(v) '1.0b1' v.info (1, 0, 'b', 1) v._cmp_info # use for comparison ((1, 0), ('b', 1), ('f',))

Thoughts? Trent -- Trent Mick trentm@gmail.com

I'd be in favor of replacing the 'b' and 'post' and so forth with symbolic constants - eg, RationalVersion((1, 0, RationalVersion.POST, 345)). If not that, then I'd at least like 'final' instead of 'f', 'beta' instead of 'b' (is that what 'b' means?) - since this doesn't necessarily need to be tied to how the version is serialized: it's for programmers to type, so the more obvious it is what things mean, the better.

Yes, it doesn't necessarily need to be tied to the version serialization, but there is some elegance if this is the case. Granted the 'f' for 'final' isn't obvious, but in the context of version strings 'b' for 'beta' and 'a' for 'alpha' is pretty obvious, no? The 'f' is just internal, anyway. I'd rather not get into the situation where we start allowing both "b" and "beta" as arguments to the constructor to mean the same thing. If people thought it would help, I'd be cool with: RationalVersion.BETA = 'b' et al. Trent -- Trent Mick trentm@gmail.com

[Tarek]

...

...

Sounds good, I'd be in favor of making RationalVersion using explicit version bits, and having some kind of function:

str2version(somestring) -> RationalVersion instance

[Trent]

...

Or we could have:

   RationalVersion(...version bits...)    RationalVersion.from_string(s)      # this is a @classmethod

[Tres]

I would prefer keeping the string version of __init__, with the "I'm in control, dammit" version reserved for the non-default factory method.

I'd tend to agree, but I don't feel strongly about it. Tarek, Why would you prefer the default constructor argument be the version bits form. Trent -- Trent Mick trentm@gmail.com

On 09-04-27 05:09 PM, Eric Smith wrote:

...

[Trent]

...

...

Or we could have:

RationalVersion(...version bits...) RationalVersion.from_string(s) # this is a @classmethod

[Tres]

...

I would prefer keeping the string version of __init__, with the "I'm in control, dammit" version reserved for the non-default factory method.

I'd tend to agree, but I don't feel strongly about it.

I agree. The more common one will be the string version, it should be __init__.

I prefer `from_string` for the following reasons: - `__init__` is typically expected to accept object components as arguments, rather than a parse-able string. - `RationalVersion.from_string('...')` is much more explicit than `RationalVersion('...')` and explicit is better than implicit. Besides, the standard library has several instances of `from_string`.

On Wed, Apr 22, 2009 at 11:12:22AM +0200, Tarek Ziadé wrote:

We worked during Pycon on version comparisons. Distutils has one but it is a bit strict, setuptools has another one, but it's a bit heuristic.

We would like to propose the inclusion for Python 2.7 of a new version comparison algorithm, based on the discussion Fedora, Ubuntu and Python people had. The plan would be to deprecate the current one (which is not really used anyway) and provide, promote this one.

I assume by "not really used" you refer to the distutils algorithm rather than the setuptools one?

Trent Mick took the lead on this work at the end of Pycon, and worked on a prototype.

It's explained here, and there's an implementation (I've put it at the top of the page for conveniency):

http://wiki.python.org/moin/Distutils/VersionComparison

I find the dot separating the "1.0" from "dev" in "1.0.dev456" unappealing. Why was it added? The current common setuptools usage is "dev" with no dot and with no requirement to have at least one digit following the "dev". (The common usage also implies tarring and feathering anyone who releases a package with 'dev' in the version number into PyPI). I'm also kind of wondering why 'dev' rather than 'pre' if we want to unambiguously distinguish prereleases from postreleases. If it's for compatibility with setuptools, then why the extra dot in front of dev? (Personally, I like 1.2 < 1.2+svn1234 < 1.2.1 as opposed to the prevailing norm of 1.2 < 1.2.1dev < 1.2.1.)

Please comment,

-0.5 for inventing a new algorithm +0.5 for using an existing one (and an additional +0.1 on top of that if it's the one used by Debian) Marius Gedminas -- I've been in the sun for a week. I took the bold step of leaving my laptop at home. I found only 4K messages pending when I returned. -- Keith Packard

On Tue, Apr 28, 2009 at 12:47:49PM -0700, Trent Mick wrote:

...

...

http://wiki.python.org/moin/Distutils/VersionComparison

I find the dot separating the "1.0" from "dev" in "1.0.dev456" unappealing.  Why was it added?

I believe the consensus at the PyCon open spaces was that it separated better in general. For example:

1.0a2.1dev1234 1.0a2.1.dev1234

I respectfully disagree with the applicability of the word "better" for these examples. "Less worse", maybe. Picking a less extreme example: 2.1.5dev1234 2.1.5.dev1234 Hm. Let me stare at it a bit more. Hm. Why not 2.1.5.dev.1234 then? Marius Gedminas -- MCSE == Minesweeper Consultant / Solitaire Expert