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

Nick Coghlan ncoghlan at gmail.com
Sun Apr 3 07:25:04 CEST 2011


On Sun, Apr 3, 2011 at 2:24 PM, Eugene Toder <eltoder at gmail.com> wrote:
>> However, I'm not sure we *can* do a general-purpose AST transformation
>> that handles both new nodes and changes to existing nodes correctly
>> for all applications.
>
> As long as both versions contain the same information we can write a
> transformation that does a near-perfect job.
> E.g. for my changes I can write a convertor that produces AST in
> almost the same form as the current one, the only change being the new
> 'docstring' attribute set to None. (That's for converting AST before
> optimizations, after optimizations it can contain nodes that couldn't
> be represented before). I believe it's similar for Try change that
> Benjamin mentioned above.
>
> Also, if written in Python, conversion can at least serve as a
> template even if it doesn't work out of the box.

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

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list