Message375948
| 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. |
|