By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,768 Members | 2,054 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,768 IT Pros & Developers. It's quick & easy.

Version Number Comparison Function

P: n/a
Is there a function for comparing version numbers?

E.g.

0.1.0 < 0.1.2
1.876b < 1.876c
3.2.2 < 3.4

Keith

Jul 18 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
On 25 Mar 2005 07:34:38 -0800, rumours say that "Keith"
<ve****@lincom-asg.com> might have written:
Is there a function for comparing version numbers?

E.g.

0.1.0 < 0.1.2
1.876b < 1.876c
3.2.2 < 3.4

Keith


Convert your version numbers into tuples:

(0, 1, 0) < (0, 1, 2)
(1, 876, 'b') < (1, 876, 'c')
(3, 2, 2) < (3, 4)

All of the above are True.
--
TZOTZIOY, I speak England very best.
"Be strict when sending and tolerant when receiving." (from RFC1958)
I really should keep that in mind when talking with people, actually...
Jul 18 '05 #2

P: n/a
On 25 Mar 2005 07:34:38 -0800, Keith <ve****@lincom-asg.com> wrote:
Is there a function for comparing version numbers?

E.g.

0.1.0 < 0.1.2
1.876b < 1.876c
3.2.2 < 3.4


Not by default AFAIK. How about something like (untested):

def test_version(v1, v2):
v1, v2 = v1.split('.'), v2.split('.')
for x, y in zip(v1, v2):
if x < y: return v1
if y > x: return v2

It assumes that v1 and v2 have the same amount of '.'s and that all of
the version numbers are of the same length (i.e. 1.1000 would be <
1.999). How general do you need to be?

Peace
Bill Mill
bill.mill at gmail.com
Jul 18 '05 #3

P: n/a
"Keith" wrote:
Is there a function for comparing version numbers?

E.g.

0.1.0 < 0.1.2
1.876b < 1.876c
3.2.2 < 3.4


the following works for many common cases:

import re

def cmpver(a, b):
def fixup(i):
try:
return int(i)
except ValueError:
return i
a = map(fixup, re.findall("\d+|\w+", a))
b = map(fixup, re.findall("\d+|\w+", b))
return cmp(a, b) # -1 if a<b, 0 if a=b, 1 if a>b
cmpver("0.1.0", "0.1.2") -1 cmpver("1.876b", "1.876c") -1 cmpver("3.2.2", "3.4")

-1

ymmv.

</F>

Jul 18 '05 #4

P: n/a
I recently saw this:

http://www.egenix.com/files/python/mxTools.html

mx.Tools.verscmp(a,b)
Compares two version strings and returns a cmp() function
compatible value (<,==,> 0). The function is useful for sorting lists
containing version strings.

The logic used is as follows: the strings are compared at each
level, empty levels defaulting to '0', numbers with attached strings
(e.g. '1a1') compare less than numbers without attachement (e.g. '1a1'
< '1).

Keith wrote:
Is there a function for comparing version numbers?

E.g.

0.1.0 < 0.1.2
1.876b < 1.876c
3.2.2 < 3.4

Keith


Jul 18 '05 #5

P: n/a
On Fri, 25 Mar 2005 17:02:31 +0100, "Fredrik Lundh" <fr*****@pythonware.com> wrote:
"Keith" wrote:
Is there a function for comparing version numbers?

E.g.

0.1.0 < 0.1.2
1.876b < 1.876c
3.2.2 < 3.4


the following works for many common cases:

import re

def cmpver(a, b):
def fixup(i):
try:
return int(i)
except ValueError:
return i
a = map(fixup, re.findall("\d+|\w+", a))
b = map(fixup, re.findall("\d+|\w+", b))
return cmp(a, b) # -1 if a<b, 0 if a=b, 1 if a>b


[OT] Visually, I like the nested def fixup, and I realize
that for cmpver execution overhead is not likely to be an issue,
but in general, what do you think of not being able
to write it that way if MAKE_FUNCTION overhead is unacceptable?

What if we had something like

@sticky('fixup') # evaluate binding only first time
def cmpver(a , b):
def fixup ... ?

Regards,
Bengt Richter
Jul 18 '05 #6

P: n/a
On Fri, 25 Mar 2005 19:23:37 GMT, rumours say that bo**@oz.net (Bengt
Richter) might have written:
On Fri, 25 Mar 2005 17:02:31 +0100, "Fredrik Lundh" <fr*****@pythonware.com> wrote:
"Keith" wrote:
Is there a function for comparing version numbers?

E.g.

0.1.0 < 0.1.2
1.876b < 1.876c
3.2.2 < 3.4


the following works for many common cases:

import re

def cmpver(a, b):
def fixup(i):
try:
return int(i)
except ValueError:
return i
a = map(fixup, re.findall("\d+|\w+", a))
b = map(fixup, re.findall("\d+|\w+", b))
return cmp(a, b) # -1 if a<b, 0 if a=b, 1 if a>b


[OT] Visually, I like the nested def fixup, and I realize
that for cmpver execution overhead is not likely to be an issue,
but in general, what do you think of not being able
to write it that way if MAKE_FUNCTION overhead is unacceptable?

What if we had something like

@sticky('fixup') # evaluate binding only first time
def cmpver(a , b):
def fixup ... ?


One of the previous related threads is this (long URL):

http://groups-beta.google.com/group/...99103bb19c7332
--
TZOTZIOY, I speak England very best.
"Be strict when sending and tolerant when receiving." (from RFC1958)
I really should keep that in mind when talking with people, actually...
Jul 18 '05 #7

P: n/a
Christos TZOTZIOY Georgiou wrote:

One of the previous related threads is this (long URL):
http://groups-beta.google.com/group/...99103bb19c7332

Another previous message on this issue:

http://groups-beta.google.com/group/...15d8b83cca5b20

Python's syntax surely is not clean enough for concise metaprogramming.
At any rate, I'd agree with Fernando's assessment:

Fernando wrote: The real problem with Python is ... Python is
going the C++ way: piling feature upon feature, adding bells
and whistles while ignoring or damaging its core design.


If the core design were better, many "new features" in Python could
have been rendered unnecessary.

Jul 18 '05 #8

P: n/a
On 29 Mar 2005 00:29:06 -0800, "El Pitonero" <pi******@gmail.com> wrote:
Christos TZOTZIOY Georgiou wrote:

One of the previous related threads is this (long URL):

http://groups-beta.google.com/group/...99103bb19c7332

Another previous message on this issue:

http://groups-beta.google.com/group/...15d8b83cca5b20

Python's syntax surely is not clean enough for concise metaprogramming.
At any rate, I'd agree with Fernando's assessment:

Fernando wrote:
The real problem with Python is ... Python is
going the C++ way: piling feature upon feature, adding bells
and whistles while ignoring or damaging its core design.


If the core design were better, many "new features" in Python could
have been rendered unnecessary.

Do you have specific recommendations that might benefit python 3000?
What better "core design" features would have eliminated what "new features"?
;-)

Regards,
Bengt Richter
Jul 18 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.