[Python-Dev] Policy for making changes to the AST (original) (raw)

Terry Reedy tjreedy at udel.edu
Mon Apr 4 21:56:16 CEST 2011

On 4/4/2011 2:00 PM, Guido van Rossum wrote:

On Mon, Apr 4, 2011 at 10:05 AM, fwierzbicki at gmail.com <fwierzbicki at gmail.com> wrote:

As a re-implementor of ast.py that tries to be node for node compatible, I'm fine with #1 but would really like to have tests that will fail in testast.py to alert me! [and] On Mon, Apr 4, 2011 at 10:38 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote: A lot of tools that work with Python source code use ast - so even though other implementations may not use the same ast "under the hood" they will probably at least want to provide a compatible implementation. IronPython is in that boat too (although I don't know if we have a compatible implementation yet - we certainly feel like we should have one). Ok, so it sounds like ast is not limited to CPython? That makes it harder to justify changing it just so as to ease the compilation process in CPython (as opposed to add new language features).

Harder, but not impossible. Moving optimizations from bytecode (where they are demonstrably a bit fragile) to ast manipulations (where we presume they will be more robust and can be broader) should be a win in itself and it also makes them potentially available to other implementations. (There would have been some advantage to making this change for 3.0 But there was also reason for as little change as needed, just as with unittest.)

Are at least some of the implementation methods similar enough that they could use the same AST? It is, after all, a semantic translation into another language, and that need not depend on subsequent transforation and compilation to the ultimate target. A multiple-implementation AST could still be x.y dependent.

-- Terry Jan Reedy

More information about the Python-Dev mailing list