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

[Benjamin Peterson]

2011/4/2 Eugene Toder <eltoder at gmail.com>:
> Hello,
>
> While working on a rewrite of peephole optimizer that works on AST
> (http://bugs.python.org/issue11549) I had to make a few changes to the
> structure of AST. The changes are described in the issue. This raises the
> question -- what is the policy for making changes to the AST? Documentation
> for ast module does not warn about possible changes, but obviously changes
> can occur, for example, when new constructs are introduced. What about other
> changes? Is there a policy for what's acceptable and how this should be
> handled?
>
> 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.

There are some AST cleanups I'd like to happen, too, such as unifying
TryExcept and TryFinally into a single node.

-- 
Regards,
Benjamin