Author ncoghlan
Recipients benjamin.peterson, brett.cannon, methane, ncoghlan, pitrou, rhettinger, serhiy.storchaka, yselivanov
Date 2018-04-21.05:29:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
If I recall Eugene Toder's previous AST-level compilation patches correctly, they handle this problem by putting the AST optimisation step *after* the output of the Py_CF_ONLY_AST step.

This meant that if you're running the source->AST step explicitly, you still get the original unoptimised AST out, which is what you actually want for a lot of source-code-analysis-or-manipulation related use cases.

The optimisation steps then all remained in the "AST -> executable opcodes" phase, they were just structured a bit differently due to the addition of an extra step (AST -> optimised AST -> executable opcodes -> optimised opcodes).

This is more work initially (since it involves building out a completely new compiler pass for the "AST -> optimised AST" step), but means that:

* existing source->AST use cases are unaffected by the compiler change
* existing AST->opcode use cases continue to benefit from all of the optimisation passes, regardless of whether those optimisations are applied at the AST or opcode level
Date User Action Args
2018-04-21 05:29:52ncoghlansetrecipients: + ncoghlan, brett.cannon, rhettinger, pitrou, benjamin.peterson, methane, serhiy.storchaka, yselivanov
2018-04-21 05:29:52ncoghlansetmessageid: <>
2018-04-21 05:29:52ncoghlanlinkissue33318 messages
2018-04-21 05:29:50ncoghlancreate