classification
Title: Change ast.__version__ calculation to provide consistent ordering
Type: Stage: resolved
Components: Library (Lib) Versions: Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: ncoghlan Nosy List: benjamin.peterson, brett.cannon, eric.araujo, loewis, ncoghlan, python-dev, r.david.murray
Priority: normal Keywords:

Created on 2011-06-07 04:12 by ncoghlan, last changed 2011-07-16 10:38 by ncoghlan. This issue is now closed.

Messages (8)
msg137786 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2011-06-07 04:12
Benjamin's AST modification checkins switched directly from the SVN revision number (as a string) to the hg revision hash.

While that preserves uniqueness, it makes ordering difficult to determine.

The last AST version in 3.2 was '82163' (and it was '82160' in 2.7).

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.

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)
msg137787 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-06-07 05:46
> 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.
msg137854 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2011-06-07 17:00
I propose we leave ast.__version__ alone. Using ast.__version__ at all should be a very advanced usecase. Generally, you should just be able to look at sys.version_info. We could document this rather than duplicating sys.version_info in ast.__version__. I think ast.__version__ is mostly useful for things like:

print("Running with Python {} and AST {}".format(sys.mercurial[2], ast.__version__)
msg137880 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-06-07 19:59
I think you should just kill ast.__version__ in that case.  There was a discussion on python-dev and packaging about __version__ and PEP 396 was the result.  If you want the VCS info put it somewhere else (like __vcs_version__?).
msg138053 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2011-06-10 06:28
sys.version_info and sys._mercurial provide all the info needed for someone (like me for mnfy) to know if their code will work against the AST nodes used by the running interpreter. I say drop __version__.
msg140477 - (view) Author: Roundup Robot (python-dev) Date: 2011-07-16 02:06
New changeset b23ad0a6cf87 by Benjamin Peterson in branch 'default':
remove ast.__version__ (closes #12273)
http://hg.python.org/cpython/rev/b23ad0a6cf87
msg140489 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-07-16 10:23
> sys.version_info and sys._mercurial provide all the info needed for someone (like me for mnfy)

Can you please elaborate? How do you know from looking at
sys._mercurial whether you can support that AST version?
sys._mercurial changes with every commit, but the AST doesn't
change that often.
msg140490 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2011-07-16 10:37
On Sat, Jul 16, 2011 at 8:24 PM, Martin v. Löwis <report@bugs.python.org> wrote:
>> sys.version_info and sys._mercurial provide all the info needed for someone (like me for mnfy)
>
> Can you please elaborate? How do you know from looking at
> sys._mercurial whether you can support that AST version?
> sys._mercurial changes with every commit, but the AST doesn't
> change that often.

For anyone not following CPython tip, the real version indicator is
sys.version_info (i.e. assuming the AST changes with each major Python
version and bumping your version check once you've determined that
your code is compatible with a later release).

Life is more difficult for anyone following CPython tip, but in that
case it is probably easier to just assume compatibility and
investigate further if a "hg pull" ever breaks anything. Since
"ast.__version__" wasn't usefully orderable post-Hg migration, the
previous best you could have done is checked for a specific version,
guaranteeing failure if we changed the AST in any respect. Agreed that
sys._mercurial changes too often to be useful in even that limited
way, though.
History
Date User Action Args
2011-07-16 10:38:00ncoghlansetmessages: + msg140490
title: Change ast.__version__ calculation to provide consistent ordering -> Change ast.__version__ calculation to provide consistent ordering
2011-07-16 10:23:59loewissetmessages: + msg140489
2011-07-16 02:06:05python-devsetstatus: open -> closed

nosy: + python-dev
messages: + msg140477

resolution: fixed
stage: resolved
2011-06-10 06:28:16brett.cannonsetmessages: + msg138053
2011-06-07 19:59:09r.david.murraysetnosy: + r.david.murray
messages: + msg137880
2011-06-07 17:00:35benjamin.petersonsetmessages: + msg137854
2011-06-07 16:50:23eric.araujosetnosy: + eric.araujo
2011-06-07 05:46:29loewissetnosy: + loewis
title: Change ast.__version__ calculation to provide consistent ordering -> Change ast.__version__ calculation to provide consistent ordering
messages: + msg137787
2011-06-07 04:12:13ncoghlancreate