Author petr.viktorin
Recipients BTaskaya, corona10, dino.viehland, eric.snow, lukasz.langa, pablogsal, petr.viktorin, shihai1991, vstinner
Date 2020-08-26.18:29:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1598466542.14.0.792134131764.issue41631@roundup.psfhosted.org>
In-reply-to
Content
Regarding ac46eb4ad6662cf6d771b20d8963658b2186c48c:
Module states come and go with the modules that contain them; if a "get_global_ast_state" or "astmodulestate_global" needs to be accessed from outside the module, it shouldn't be module state :/

----

So, the main issue here is that the AST types are not used only by the _ast module, but by the interpreter itself: the compile() builtin and Py_CompileStringObject.

I see two ways of fixing this properly:

1. All the classes _ast provides should be built-in, like, say, `function`. (Currently, that means they should be static types; later they could be per-interpreter.)
The _ast module should merely expose them from Python, like the `types` module exposes the function type.
This would mean that calling Py_CompileStringObject with PyCF_ONLY_AST will be independent of the _ast module.

2. The mod2obj/obj2mod functions, called by e.g. compile(..., PyCF_ONLY_AST), should:
* import the _ast module
* call a Python-accessible function, e.g. _ast._mod2obj
This would mean replacing the _ast module (in sys.modules or through an import hook, which you can do from Python code) will affect what AST types will be used throughout the interpreter.
History
Date User Action Args
2020-08-26 18:29:02petr.viktorinsetrecipients: + petr.viktorin, vstinner, dino.viehland, lukasz.langa, eric.snow, corona10, pablogsal, BTaskaya, shihai1991
2020-08-26 18:29:02petr.viktorinsetmessageid: <1598466542.14.0.792134131764.issue41631@roundup.psfhosted.org>
2020-08-26 18:29:02petr.viktorinlinkissue41631 messages
2020-08-26 18:29:01petr.viktorincreate