RetroSearch Browse

Sun Apr 3 07:42:24 CEST 2011 · https://mail.python.org/pipermail/python-dev/2011-April/110408.html

> 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2011-April/110408.html below:

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