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

[Dino Viehland]

Guido 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).

Even so I think adding new features does allow new changes to the AST.  We'll
need to do the work to add support for the new features anyway so updating the
AST accordingly won't be much more work.  I agree with Frank that as long as there
are tests for the new features it's fine.  I think it'll also be better for consumers who
would probably prefer to see a YieldFrom node rather than its expansion (and not
all new language features will necessarily have a reasonable  expansion - consider if
goto ever happened ;) ).

Also, IronPython doesn't have ast yet but I think it has been requested that we 
implement it - we just haven't gotten around to it yet.

So I'm +1 on allowing changes to it.