[issue39686] add dump_json to ast module

[Richard K]

Richard K <qpotizo at gmail.com> added the comment:

> I don't think the clang argument holds because clang is a command-line tool after all and it makes sense that it can produce several outputs while the ast module is exposes APIs that you can further process inside the language. Having json from the clang output will require more than one tool if clang does not support it while doing it in Python only requires Python.

I see what you mean. I was just trying to illustrate that such a feature is desired by some. 

Perhaps 'Python only requires Python' means that Python _could_ be the first widely used language with such a superior meta-programming feature with respect to AST analysis/code generation. 


> > it appears that they do so in non-standard ways.

> Can you clarify what do you mean with that? 

By non-standard I mean that the resulting json does not follow the structure of the tree explicitly. For example with ast2json, '"_type": "Print"' includes a (somewhat misleading) key that is not represented in the actual AST. 

Example of ast2json output (example found here, https://github.com/YoloSwagTeam/ast2json#example),

{
    "body": [
        {
            "_type": "Print",
            "nl": true,
            "col_offset": 0,
            "dest": null,
            "values": [
                {
                    "s": "Hello World!",
                    "_type": "Str",
                    "lineno": 1,
                    "col_offset": 6
                }
            ],
            "lineno": 1
        }
    ],
    "_type": "Module"
}


> Just to clarify: ast.dump *will* fail with a more deph object as well, I am not claiming that ast.dump will parse everything because of course suffers the same problem.

Makes sense. As you mentioned, these are edge cases which I assume will not be an issue for those seeking to gain the benefits of 'ast.dump_json'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39686>
_______________________________________