On Sun, Apr 3, 2011 at 12:07 PM, Benjamin Peterson <benja...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
