On Sun, Apr 3, 2011 at 3:42 PM, Eugene Toder <elto...@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 | 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
