Martin v. Löwis mar...@v.loewis.de added the comment:
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
Nick Coghlan ncogh...@gmail.com added the comment:
On Sat, Jul 16, 2011 at 8:24 PM, Martin v. Löwis rep...@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
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset b23ad0a6cf87 by Benjamin Peterson in branch 'default':
remove ast.__version__ (closes #12273)
http://hg.python.org/cpython/rev/b23ad0a6cf87
--
nosy: +python-dev
resolution: - fixed
stage: -
Brett Cannon br...@python.org added the comment:
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__.
--
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12273
___
___
Python-bugs-list
Benjamin Peterson benja...@python.org added the comment:
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
R. David Murray rdmur...@bitdance.com added the comment:
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__?).
New submission from Nick Coghlan ncogh...@gmail.com:
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'
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.zzz'
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