[Python-Dev] Two laments about CPython's AST Nodes

["Martin v. Löwis"]

> Now on to the complaints: Though I recently added support for this in
> Jython, I don't like that nodes can be defined without required
> attributes, for example:
> 
> node = ast.Assign()

I think we disagree in two points in our evaluation of this behavior:

a) ast.Assign is *not* a node of the CPython AST. The CPython AST is
   a set of C structures in Include/Python-ast.h. ast.Assign is merely
   a mirror structure of that.

b) it is, IMO, not reasonable to require users who create AST trees
   out of nothing to have correct trees at all times. I.e. it must be
   possible to represent incorrect trees.

c) the AST is *not* part of the Python language or library. It may
   change at any time without notice, and Jython is not required to
   duplicate its behavior exactly.

[so that's three items - as there should be in any good list of
two items :-]

> Which, when you try to parse, blows up with "TypeError: Assign field
> "targets" must be a list, not a str".  I'd be much happier if this
> blew up right away when you try to make the assignment.  At the
> moment, this is how it works in Jython (though I could support this
> with some contorting).

What precisely is it that makes this difficult to implement. If you
would follow CPython's implementation strategy (i.e. generate glue
code out of ASDL), I feel that it should be straight-forward to provide
exactly the same behavior in Jython.

> BTW -- I *am* volunteering to attempt to implement these things in
> CPython if there is support :)

I'm not sure I can support such a change. Giving the child nodes at
creation time, optionally, would be fine with me. Requiring the
tree to conform to the grammar at all times is unreasonable, IMO
(you can't simultaneously create all nodes in the tree and glue
them together, so you have to create the tree in steps - which means
that it will be intermittently incorrect).

You seem to propose some middle ground, but I'm not sure I understand
what that middle ground is.

Regards,
Martin