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

Nick Coghlan ncoghlan at gmail.com
Sun Apr 3 04:51:37 CEST 2011

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

More information about the Python-Dev mailing list