Mailman 3 version compare function into main lib - Python-Dev

version compare function into main lib

anatoly techtonik

27 Mar 2009 27 Mar '09

7:42 a.m.

Greetings, Correct me if I wrong, but shouldn't Python include function for version comparisons? The problem of splitting a string like "10.3.40-beta" into tuple for cmp() seems to be dead simple, but the code gets bulky with excepting errors arised from converting resulting strings for arithmetic comparison. No wonder people advise to use ready distutils.version module, but that's not good to introduce such dependency for main program logic. What do you think about adding cmpversions(first, second, strict=false) based on distutils into main lib? Will it be more appropriate to isolate the function into "versions" module? Should it be rewritten to remove re dependency in this case? Distutils version comparisons: http://svn.python.org/view/python/branches/release26-maint/Lib/distutils/ver... --anatoly t.

Show replies by date

Eric Smith

27 Mar 27 Mar

10:57 a.m.

anatoly techtonik wrote:

...

Correct me if I wrong, but shouldn't Python include function for version comparisons?

<snip>

...

What do you think about adding cmpversions(first, second, strict=false) based on distutils into main lib?

distutils _is_ already in the "main lib", that is, the standard library.

...

Will it be more appropriate to isolate the function into "versions" module? Should it be rewritten to remove re dependency in this case?

Given that re is also in the standard library, and this is hardly speed critical, I'd say no.

...

Distutils version comparisons: http://svn.python.org/view/python/branches/release26-maint/Lib/distutils/ver...

I don't see the point of moving this, unless it's part of some larger, radical "fix distutils" effort. And even then I'm not convinced. This probably belongs on the python-ideas mailing list, or on the distutils SIG list. I expect you'll see a lot of discussion on distutils SIG list in the coming days. Eric.

Greg Ewing

11:20 a.m.

anatoly techtonik wrote:

...

Correct me if I wrong, but shouldn't Python include function for version comparisons?

Can't you just compare sys.version_info tuples?

...

...
...
sys.version_info (2, 5, 0, 'final', 0)

Assuming the other possibilities for 'final' are 'alpha' and 'beta', these should compare in the right order. -- Greg

"Martin v. Löwis"

3:11 p.m.

...

Correct me if I wrong, but shouldn't Python include function for version comparisons?

On the packaging summit yesterday, people agreed that yes, we should have something like that in the standard library, and it should be more powerful than what distutils currently offers. There was no conclusion of how specifically that functionality should be offered; several people agreed that Python should mandate a standard format, which it is then able to compare. So you might not be able to spell it "10.3.40-beta", but perhaps "10.3.40b1" or "10.3.40~beta". Regards, Martin

Mart Sõmermaa

3:28 p.m.

See http://wiki.python.org/moin/ApplicationInfrastructure , "Version handling" below for a possible strict version API. The page is relevant for the general packaging discussion as well, although it's not fully fleshed out yet. MS On Fri, Mar 27, 2009 at 5:11 PM, "Martin v. Löwis" wrote:

...

Correct me if I wrong, but shouldn't Python include function for

...
version comparisons?

On the packaging summit yesterday, people agreed that yes, we should have something like that in the standard library, and it should be more powerful than what distutils currently offers.

There was no conclusion of how specifically that functionality should be offered; several people agreed that Python should mandate a standard format, which it is then able to compare. So you might not be able to spell it "10.3.40-beta", but perhaps "10.3.40b1" or "10.3.40~beta".

Regards, Martin

Eric Smith

4:01 p.m.

Martin v. Löwis wrote:

...

...
Correct me if I wrong, but shouldn't Python include function for version comparisons?

On the packaging summit yesterday, people agreed that yes, we should have something like that in the standard library, and it should be more powerful than what distutils currently offers.

Yes.

...

There was no conclusion of how specifically that functionality should be offered; several people agreed that Python should mandate a standard format, which it is then able to compare. So you might not be able to spell it "10.3.40-beta", but perhaps "10.3.40b1" or "10.3.40~beta".

I got the impression that people are generally happy with what setuptools provides for version parsing and comparison. Does anyone think that's not a good model? Eric.

M.-A. Lemburg

4:08 p.m.

On 2009-03-27 17:01, Eric Smith wrote:

...

Martin v. Löwis wrote:

...
...
Correct me if I wrong, but shouldn't Python include function for version comparisons?

On the packaging summit yesterday, people agreed that yes, we should have something like that in the standard library, and it should be more powerful than what distutils currently offers.

Yes.

...
There was no conclusion of how specifically that functionality should be offered; several people agreed that Python should mandate a standard format, which it is then able to compare. So you might not be able to spell it "10.3.40-beta", but perhaps "10.3.40b1" or "10.3.40~beta".

I got the impression that people are generally happy with what setuptools provides for version parsing and comparison.

Does anyone think that's not a good model?

Instead of trying to parse some version string, distutils should require defining the version as tuple with well-defined entries - much like what we have in sys.version_info for Python. The developer can then still use whatever string format s/he wants. The version compare function would then work on this version tuple and probably be called cmp() (at least in Python 2.x ;-). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 27 2009)

...

...
...
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

2009-03-19: Released mxODBC.Connect 1.0.1 http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

Mart Sõmermaa

4:21 p.m.

...

Instead of trying to parse some version string, distutils should require defining the version as tuple with well-defined entries - much like what we have in sys.version_info for Python.

The developer can then still use whatever string format s/he wants.

The version compare function would then work on this version tuple and probably be called cmp() (at least in Python 2.x ;-).

Except there need to be functions for parsing the tuple from a string and preferably a canonical string representation to ease that parsing. Hence the Version class in "Version Handling" referred to above.

Eric Smith

4:30 p.m.

Mart Sõmermaa wrote:

...

Instead of trying to parse some version string, distutils should require defining the version as tuple with well-defined entries - much like what we have in sys.version_info for Python.

The developer can then still use whatever string format s/he wants.

The version compare function would then work on this version tuple and probably be called cmp() (at least in Python 2.x ;-).

Except there need to be functions for parsing the tuple from a string and preferably a canonical string representation to ease that parsing. Hence the Version class in "Version Handling" referred to above.

Right. For example, say you need to specify in a config file that your package requires version 1.3.4 of some other tool. I think the only rational way to do this is in a string, and be able to parse the version number (possibly into a tuple) and compare it with other version numbers. I don't think you want to directly specify the tuple in such a case. Eric.

P.J. Eby

4:39 p.m.

At 05:08 PM 3/27/2009 +0100, M.-A. Lemburg wrote:

...

On 2009-03-27 17:01, Eric Smith wrote:

...
Martin v. Löwis wrote:

...
...
Correct me if I wrong, but shouldn't Python include function for version comparisons?

On the packaging summit yesterday, people agreed that yes, we should have something like that in the standard library, and it should be more powerful than what distutils currently offers.

Yes.

...
There was no conclusion of how specifically that functionality should be offered; several people agreed that Python should mandate a standard format, which it is then able to compare. So you might not be able to spell it "10.3.40-beta", but perhaps "10.3.40b1" or "10.3.40~beta".

I got the impression that people are generally happy with what setuptools provides for version parsing and comparison.

Does anyone think that's not a good model?

Instead of trying to parse some version string, distutils should require defining the version as tuple with well-defined entries - much like what we have in sys.version_info for Python.

The developer can then still use whatever string format s/he wants.

The version compare function would then work on this version tuple and probably be called cmp() (at least in Python 2.x ;-).

By the way, pkg_resources.parse_version of course returns a tuple that can be compared with cmp().

"Martin v. Löwis"

7:49 p.m.

...

I got the impression that people are generally happy with what setuptools provides for version parsing and comparison.

Does anyone think that's not a good model?

Procedurally, I think it's a very bad approach. I don't mind the setuptools implementation being used as a basis (assuming it gets contributed), but *independently* I think a specfication is needed what version strings it actually understands. Such specification must precede the actual implementation (in distutils). Regards, Martin

Eric Smith

7:52 p.m.

Martin v. Löwis wrote:

...

...
I got the impression that people are generally happy with what setuptools provides for version parsing and comparison.

Does anyone think that's not a good model?

Procedurally, I think it's a very bad approach. I don't mind the setuptools implementation being used as a basis (assuming it gets contributed), but *independently* I think a specfication is needed what version strings it actually understands. Such specification must precede the actual implementation (in distutils).

Agreed. Specifications first, for all of this work.

Ben Finney

10:37 p.m.

"Martin v. Löwis" writes:

...

I don't mind the setuptools implementation being used as a basis (assuming it gets contributed), but *independently* I think a specfication is needed what version strings it actually understands. Such specification must precede the actual implementation (in distutils).

Yes, please. The comparison of version strings needs to be easily done by non-Python programs (e.g. tools for packaging Python distributions), so a specification that can be implemented in other languages or environments is a must. -- \ “I was in the grocery store. I saw a sign that said ‘pet | `\ supplies’. So I did. Then I went outside and saw a sign that | _o__) said ‘compact cars’.” —Steven Wright | Ben Finney

Mart Sõmermaa

28 Mar 28 Mar

10:06 a.m.

On Sat, Mar 28, 2009 at 12:37 AM, Ben Finney < bignose+hates-spam@benfinney.id.au >wrote:

...

"Martin v. Löwis" writes:

...
I don't mind the setuptools implementation being used as a basis (assuming it gets contributed), but *independently* I think a specfication is needed what version strings it actually understands. Such specification must precede the actual implementation (in distutils).

Yes, please. The comparison of version strings needs to be easily done by non-Python programs (e.g. tools for packaging Python distributions), so a specification that can be implemented in other languages or environments is a must.

There's a specification in http://wiki.python.org/moin/ApplicationInfrastructure , see "Version API" below (at least, it's a start).

5507

Age (days ago)

5508

Last active (days ago)

List overview

Download

13 comments

8 participants

participants (8)

"Martin v. Löwis"
anatoly techtonik
Ben Finney
Eric Smith
Greg Ewing
M.-A. Lemburg
Mart Sõmermaa
P.J. Eby

version compare function into main lib

Ben Finney

tags

participants (8)