homepage

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)

> 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.

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__)

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__?).

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__.

New changeset b23ad0a6cf87 by Benjamin Peterson in branch 'default':
remove ast.__version__ (closes #12273)
http://hg.python.org/cpython/rev/b23ad0a6cf87 

> 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.

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.