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

Nick Coghlan ncoghlan at gmail.com
Sun Apr 3 08:44:41 CEST 2011

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.getdocstring will need to know whether docstring was populated or it needs to look in the body. This can be solved by attaching astversion 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

More information about the Python-Dev mailing list