On Sun, Apr 3, 2011 at 3:42 PM, Eugene Toder <eltoder at gmail.com> wrote: >> If it's do-able, your option 2 is probably the way to go. Out of the >> box, it may just need to raise an exception if asked to down-convert >> code that uses new constructs that can't readily be expressed using >> the old AST (I'm specifically thinking of the challenge of converting >> PEP 380's yield-from). > > I was talking only about changes in AST for existing constructs. New > language features is another dimension. For example, we can leave them > even in "old" trees, so that they can be supported in existing code > with minimal changes. Or we can throw, forcing everyone who wants to > process them to catch up with all other AST changes. I wonder if there's any existing research on the topic - we can't be the first people to confront these kinds of problems. > I realized I overlooked one problem with supporting multiple versions > of AST. Functions from ast module might need to know which AST version > they've got. For example, ast.get_docstring will need to know whether > docstring was populated or it needs to look in the body. This can be > solved by attaching ast_version to affected nodes when converting. Or just have a top level version node. If it isn't there, then it's version 1. (Although that could make working on subsections of the AST a little trickier) 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