[Python-Dev] Policy for making changes to the AST

[Nick Coghlan]

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