This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients benjamin.peterson, brett.cannon, eric.araujo, loewis, ncoghlan, python-dev, r.david.murray
Date 2011-07-16.10:37:59
SpamBayes Score 1.7419022e-10
Marked as misclassified No
Message-id <CADiSq7d-qmfya_riBm2sMqrSDvuvqNxMwqi_5xHkV=-e3j4pHw@mail.gmail.com>
In-reply-to <4E2166BE.4020608@v.loewis.de>
Content
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:00ncoghlansetrecipients: + ncoghlan, loewis, brett.cannon, benjamin.peterson, eric.araujo, r.david.murray, python-dev
2011-07-16 10:37:59ncoghlanlinkissue12273 messages
2011-07-16 10:37:59ncoghlancreate