[issue12273] Change ast.__version__ calculation to provide consistent ordering

Nick Coghlan added the comment: On Sat, Jul 16, 2011 at 8:24 PM, Martin v. Löwis 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 th

[issue12273] Change ast.__version__ calculation to provide consistent ordering

Martin v. Löwis 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 every commit, but

[issue12273] Change ast.__version__ calculation to provide consistent ordering

Roundup Robot 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: -> committed/rejected status: open -> closed ___

[issue12273] Change ast.__version__ calculation to provide consistent ordering

Brett Cannon 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__. -- ___ Pyt

[issue12273] Change ast.__version__ calculation to provide consistent ordering

R. David Murray 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__?). -- nosy: +r.david.mu

[issue12273] Change ast.__version__ calculation to provide consistent ordering

Benjamin Peterson 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 ast.__version__. I

[issue12273] Change ast.__version__ calculation to provide consistent ordering

Changes by Éric Araujo : -- nosy: +eric.araujo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue12273] Change ast.__version__ calculation to provide consistent ordering

Martin v. Löwis 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 > higher t

[issue12273] Change ast.__version__ calculation to provide consistent ordering

New submission from Nick Coghlan : 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' i