Martin v. Löwis <mar...@v.loewis.de> added the comment: > I would like to change the version number calculation to something > like: > > '9.x.y.zzzzzzz' > > where > > 9 is a prefix to get 3.3+ ast.__version__ values to sort higher than > earlier versions x.y is the Python version so later versions sort > higher than earlier versions in the future zzzzzz is the hg version > id, so versions during development of a release remain unique, even > if they can't be readily ordered.
I'd drop the 9. part. People doing comparison on these numbers possibly performed int() conversions first (expecting that svn revisions might have exceeded 100,000 some day); they would have to special-case 3.3 anyway. Also, in the long run, the 2.x/3.1/3.2 copies of ast will be gone, and we are stuck with this odd prefix. OTOH, most people probably don't do ordering comparisons at all, but have explicit lists of versions they support (barking if it's an unknown version); those won't be helped by the 9. prefix at all. > This would require changes to ast.py (to add the 9.x.y prefix) and to > release.py (to check that the 'x.y' prefix is correct in the current > release) I'd synthesize x.y from patchlevel.h, in which case it would be fully automatic again. ---------- nosy: +loewis title: Change ast.__version__ calculation to provide consistent ordering -> Change ast.__version__ calculation to provide consistent ordering _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12273> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
