Author ncoghlan
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:39:44
SpamBayes Score 3.56784e-08
Marked as misclassified No
Message-id <1301225985.07.0.994816210148.issue11549@psf.upfronthosting.co.za>
In-reply-to
Content
I think the biggest thing to take out of my review is that I strongly encourage deferring the changes for 5(b) and 5(c).

I like the basic idea of using a template-based approach to try to get rid of a lot of the boilerplate code currently needed for AST visitors.

Providing a hook for optimisation in Python (as Dave Malcolm's approach does) is valuable as well, but I don't think the two ideas need to be mutually exclusive.

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).
History
Date User Action Args
2011-03-27 11:39:45ncoghlansetrecipients: + ncoghlan, brett.cannon, georg.brandl, rhettinger, terry.reedy, mark.dickinson, pitrou, nadeem.vawda, benjamin.peterson, alex, Trundle, dmalcolm, daniel.urban, santoso.wijaya, eltoder
2011-03-27 11:39:45ncoghlansetmessageid: <1301225985.07.0.994816210148.issue11549@psf.upfronthosting.co.za>
2011-03-27 11:39:44ncoghlanlinkissue11549 messages
2011-03-27 11:39:44ncoghlancreate