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

[Guido van Rossum]

On Sun, Apr 3, 2011 at 4:17 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 3 April 2011 07:55, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>>> 1. Do nothing. This will break code that currently uses AST, but doesn't add
>>> any complexity to cpython.
>>
>> I'm in favor of this approach as well. Notice that there is
>> ast.__version__ precisely so that applications can support multiple AST
>> versions.
>
> This might be a suitable topic for a post to "Python Insider" - as
> it's a policy question, that would make the discussion known to a
> wider audience, giving people with an interest the opportunity to
> comment. Hopefully, that also makes the "Do Nothing" approach more
> acceptable to the wider Python community by publicising the
> implications well in advance.
>
> If there are no objections (I'm conscious that we don't want every
> python-dev discussion dumped onto Python Insider) I'll post a short
> article once a consensus has been reached.

Agreed, it would be good to know what people do with AST nodes before
going too far.

In the mean time, until we hear differently, I'm also in favor of #1
(do nothing). I would (perhaps redundantly) say that such changes
should only go into new major releases (i.e. 3.3 right now), not
backported into bugfix releases (e.g. 3.2.1). AFAIK the AST is
CPython-specific so should be treated with the same attitude as
changes to the bytecode. That means, do it conservatively, since there
*are* people who like to write tools that manipulate or analyze this,
and while they know they're doing something CPython and
version-specific, they should not be broken by bugfix releases, since
the people who *use* their code probably have no idea of the deep
magic they're depending on.

-- 
--Guido van Rossum (python.org/~guido)