2011/4/2 Eugene Toder <elto...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
