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

Eugene Toder eltoder at gmail.com
Sun Apr 3 07:42:24 CEST 2011

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 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.

Eugene

More information about the Python-Dev mailing list