• Better error messages with punctuation
• Py_UNREACHABLE() for unreachable states
• Removal of several 'unused' and 'undocumented (in Zephyr ASDL spec) built-in types.

You just read my thoughts. That's what I was going to do tonight. ;)

You just read my thoughts. That's what I was going to do tonight. ;)

:) Awesome. Well I'll plan to continue this; @pablogsal and I was discussing the idea of extracting _ast.AST subclasses to python level (which would save a lot of time for new additions). So my primary goal is clearing bunch of old stuff / making it extendable and clean.

Currently working on implementing some items from this TODO https://github.com/eliben/asdl_parser/blob/master/TODO

I was also thinking about getting rid of "string" nodes and just use Constant for those. Having the strings raw make the AST inconsistent because nodes that are 'strings' do not have line numbers and other metadata, making tools that need the source to report stuff more complex than it should.

What are your opinions on this @serhiy.storchaka and @BTaskaya?

I was also thinking about getting rid of "string" nodes and just use Constant for those. Having the strings raw make the AST inconsistent because nodes that are 'strings' do not have line numbers and other metadata, making tools that need the source to report stuff more complex than it should.

I'm +1 on that (especially for finding import aliases, as we discussed earlier), if necessary precautions happen to ensure minimum breakage (from what I understand, it is something that will break everyone's code. Maybe we can implement custom Constant.__str__? and other different things to ensure it breaks small).

"string" is only used for

• type_comment in a number of statements
• kind in Constant
• tag in type_ignore

For which of them a line number is meaningful and useful?

For which of them a line number is meaningful and useful?

Apologies, I was thinking of 'identifier', which is basically a PyObject representing a string. For instance, when parsing function calls like

x = ast.parse("f(x=435)")

the 'arg' attribute of the keyword is just the string 'x', without any metadata about it (like column offset and such).

Oh, I confuse with it identifier. IMHO replacing identifier with Constant would infer position in some cases.

A real world example would be tools like unimport, that try to remove a certain part of import by looking start/end column offsets. Before (lib2to3), it was using tokens to manipulate source, and what I can tell is that having position information on multi line from imports would be a life saver for tool authors.

New changeset 091951a by Batuhan Taskaya in branch 'master':
bpo-40528: Improve and clear several aspects of the ASDL definition code for the AST (GH-19952)
091951a

Next is using asdl_int_seq for all simple sum types, and not for only cmpop. Looks like it is hardcoded to use it, and I plan to refactor this in a way that might save some time in python implementation of classes (also it will solve this bug). For not conflicting, I'll wait GH 19968.

New changeset 63b8e0c by Batuhan Taskaya in branch 'master':
bpo-40528: Improve AST generation script to do builds simultaneously (GH-19968)
63b8e0c

New changeset 35ad425 by Batuhan Taskaya in branch 'main':
bpo-40528: Implement a metadata system for ASDL Generator (GH-20193)
35ad425

New changeset 6c76df2 by Batuhan Taskaya in branch 'main':
bpo-40528: move asdl identifier collection to the new metadata system (GH-26858)
6c76df2

New changeset 107a2c5 by Batuhan Taskaya in branch 'main':
bpo-40528: fix is_simple(sum)s behavior for attributes (GH-26918)
107a2c5

These were all the cleanups on my checklist, so can close the issue now. I'll probably create other issues if something additional comes up