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 pitrou
Recipients Trundle, alex, benjamin.peterson, brett.cannon, daniel.urban, dmalcolm, eltoder, georg.brandl, mark.dickinson, nadeem.vawda, ncoghlan, pitrou, rhettinger, santoso.wijaya, terry.reedy
Date 2011-03-27.11:44:43
SpamBayes Score 4.8370435e-08
Marked as misclassified No
Message-id <1301226281.3568.3.camel@localhost.localdomain>
In-reply-to <>
> As a more general policy question... where do we stand in regards to
> backwards compatibility of the AST? The ast module docs don't have any
> caveats to say that it may change between versions, but it obviously
> *can* change due to new language constructs (if nothing else).

Yes, but can existing constructs produce a different structure from one
Python version to another?
It seems to me that the ast module is the recommended way to inspect the
structure of Python code (much more so that bytecode or concrete syntax
trees). Perhaps the optimizations can leave the initial ast intact?
Perhaps with an additional API to get the optimized ast as well?
Date User Action Args
2011-03-27 11:44:44pitrousetrecipients: + pitrou, brett.cannon, georg.brandl, rhettinger, terry.reedy, mark.dickinson, ncoghlan, nadeem.vawda, benjamin.peterson, alex, Trundle, dmalcolm, daniel.urban, santoso.wijaya, eltoder
2011-03-27 11:44:43pitroulinkissue11549 messages
2011-03-27 11:44:43pitroucreate