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

[Nick Coghlan]

On Sun, Apr 3, 2011 at 12:07 PM, Benjamin Peterson <benjamin at python.org> wrote:
>> Assuming we do want to make changes (not just extensions for new language
>> features), I see 3 options for handling them:
>>
>> 1. Do nothing. This will break code that currently uses AST, but doesn't add
>> any complexity to cpython.
>
> I must say I prefer this option. I don't know how many people are
> depending on AST, but I think they can expect it be broken
> occasionally. AST analyzing code can expect to be broken anyway every
> version new semantics are added.
>
> Maintaining versioned asts and converting between them is just clunky.

This is my preference as well, but I wanted to give *consumers* of the
AST a chance to scream at us before we break their world. The
compatibility problem doesn't go away if we ignore it - it just
devolves to the people doing the AST manipulation to invent their own
way of handling any cross-version compatibility dramas that arise.

However, I'm not sure we *can* do a general-purpose AST transformation
that handles both new nodes and changes to existing nodes correctly
for all applications. What changes are needed and/or acceptable will
likely be very heavily dependent on the specifics of what people are
doing with the AST.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia