Title: Implement __repr__ methods for AST classes
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.9
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: BTaskaya, cool-RR, pablogsal, serhiy.storchaka, vstinner
Priority: normal Keywords:

Created on 2020-02-21 18:05 by cool-RR, last changed 2020-10-30 13:00 by vstinner. This issue is now closed.

Messages (7)
msg362419 - (view) Author: Ram Rachum (cool-RR) * Date: 2020-02-21 18:05
I was playing with the `ast` library today, and it's frustrating to see objects like these:

    [<_ast.Import object at 0x00000000033FB048>,
     <_ast.Import object at 0x00000000033FB0F0>,
     <_ast.ImportFrom object at 0x00000000033FB160>,
     <_ast.Import object at 0x00000000033FB1D0>,
     <_ast.Assign object at 0x00000000033FB240>,
     <_ast.If object at 0x00000000033FB630>]

A little bit more information about each object in the `__repr__` would make this module much easier to work with.
msg362423 - (view) Author: Batuhan Taskaya (BTaskaya) * (Python committer) Date: 2020-02-21 19:11
What kind of repr do you have in your mind? If the repr you are thinking contains field information, it would be no-go. Fields of AST objects can contain other objects and fields of that objects can contain more objects (this goes up to the recursion limit where the child can not be no longer calculated). This is why we have ast.dump instead. For small debuggings there are 3rd party libraries (e.g: asteria) which adds __repr__ on runtime for working on nodes, but on a real application this can cause more problem then it benefits.
msg362424 - (view) Author: Ram Rachum (cool-RR) * Date: 2020-02-21 19:26
I understand that we have to be really careful in including information that could have unlimited size. But I think we have lots of information that isn't that way.

For example, for ClassDef and FunctionDef objects, we could include the name. For Assign, we could include the lhs. For Import, we could include the module name, etc.

And for all objects, we could include the number of descendants that they have, so people could more easily understand which are tiny and which are huge.
msg362433 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-02-21 21:02
For more informative representation you can use ast.dump().
msg379950 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-10-30 11:56
I'm not sure that it's a good idea to make repr(_ast.AST) longer. I suggest to reject this feature request. As Serhiy wrote, ast.dump() can already be used.
msg379952 - (view) Author: Batuhan Taskaya (BTaskaya) * (Python committer) Date: 2020-10-30 12:02
> I suggest to reject this feature request

msg379960 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-10-30 13:00
I reject the feature request.

While repr() on AST nodes could be enhanced for some specific nodes, you have to know that the code is mostly implemented in C which make enhancements non-trivial. Moreover, this code (Python/Python-ast.c) is generated by a script (Parser/ which makes it even worse to enhance.

I suggest you to develop tooling outside of the stdlib to format an AST tree or a list of AST nodes, something like pprint and reprlib modules. It would benefit to more Python versions and will give you way more freedom on how to format these nodes.
Date User Action Args
2020-10-30 13:00:56vstinnersetstatus: open -> closed
resolution: rejected
messages: + msg379960

stage: resolved
2020-10-30 12:02:57BTaskayasetmessages: + msg379952
2020-10-30 11:56:14vstinnersetnosy: + vstinner
messages: + msg379950
2020-02-27 20:51:19brett.cannonsetnosy: - brett.cannon
2020-02-21 21:02:12serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg362433
2020-02-21 20:01:25rhettingersetnosy: + brett.cannon
2020-02-21 19:26:21cool-RRsetmessages: + msg362424
2020-02-21 19:11:18BTaskayasetmessages: + msg362423
2020-02-21 18:41:10xtreaksetnosy: + pablogsal, BTaskaya
2020-02-21 18:05:03cool-RRcreate