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

Benjamin Peterson benjamin at python.org
Sun Apr 3 04:07:06 CEST 2011

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

More information about the Python-Dev mailing list