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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4