[Python-Dev] PEP 396, Module Version Numbers

Toshio Kuratomi a.badger at gmail.com
Thu Apr 7 18:13:55 CEST 2011


On Wed, Apr 06, 2011 at 11:04:08AM +0200, John Arbash Meinel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> ...
> > #. ``__version_info__`` SHOULD be of the format returned by PEP 386's
> >    ``parse_version()`` function.
> 
> The only reference to parse_version in PEP 386 I could find was the
> setuptools implementation which is pretty odd:
> 
> > 
> > In other words, parse_version will return a tuple for each version string, that is compatible with StrictVersion but also accept arbitrary version and deal with them so they can be compared:
> > 
> >>>> from pkg_resources import parse_version as V
> >>>> V('1.2')
> > ('00000001', '00000002', '*final')
> >>>> V('1.2b2')
> > ('00000001', '00000002', '*b', '00000002', '*final')
> >>>> V('FunkyVersion')
> > ('*funkyversion', '*final')
> 
Barry -- I think we want to talk about NormalizedVersion.from_parts() rather
than parse_version().

> bzrlib has certainly used 'version_info' as a tuple indication such as:
> 
> version_info = (2, 4, 0, 'dev', 2)
> 
> and
> 
> version_info = (2, 4, 0, 'beta', 1)
> 
> and
> 
> version_info = (2, 3, 1, 'final', 0)
> 
> etc.
> 
> This is mapping what we could sort out from Python's "sys.version_info".
> 
> The *really* nice bit is that you can do:
> 
> if sys.version_info >= (2, 6):
>   # do stuff for python 2.6(.0) and beyond
> 
<nod>  People like to compare versions and the tuple forms allow that.  Note
that the tuples you give don't compare correctly.  This is the order that
they sort:

(2, 4, 0)
(2, 4, 0, 'beta', 1)
(2, 4, 0, 'dev', 2)
(2, 4, 0, 'final', 0)

So that means, snapshot releases will always sort after the alpha and beta
releases (and release candidate if you use 'c' to mean release candidate).
Since the simple (2, 4, 0) tuple sorts before everything else, a comparison
that doesn't work with the 2.4.0-alpha (or beta or arbitrary dev snapshots)
would need to specify something like:

(2, 4, 0, 'z')

NormalizedVersion.from_parts() uses nested tuples to handle this better.
But I think that even with nested tuples a naive comparison fails since most
of the suffixes are prerelease strings.  ie: ((2, 4, 0),) < ((2, 4, 0),
('beta', 1))

So you can't escape needing a function to compare versions.
(NormalizedVersion does this by letting you compare NormalizedVersions
together).  Barry if this is correct, maybe __version_info__ is useless and
I shouldn't have brought it up at pycon?

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110407/ac5eeef8/attachment.pgp>


More information about the Python-Dev mailing list