[Python-Dev] Policy for making changes to the AST

[Terry Reedy]

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 test_ast.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