STINNER Victor <[email protected]> added the comment:
_PyWarnings_Init() initializes tstate->interp->warnings which is the module
state of the warnings module:
WarningsState *st = _Warnings_GetState();
if (st == NULL) {
goto error;
}
if (_Warnings_InitState(st) < 0) {
goto error;
}
In Python 2, _PyWarnings_Init() called Py_InitModule3() which immediately
stored the _warnings module to sys.modules['_warnings'].
In Python 3, _PyWarnings_Init() calls PyModule_Create() which creates a module
but doesn't add it to sys.modules.
I don't think that removing _PyWarnings_Init() call from pylifecycle.c is
correct. We want the _warnings module to be ready as early as possible.
The problem is that pylifecycle.c creates a module object which is not stored
anywhere:
/* Initialize _warnings. */
if (_PyWarnings_Init() == NULL) {
return _PyStatus_ERR("can't initialize warnings");
}
pylifecycle.c should only call _Warnings_InitState() without creating a module.
There are C functions which access the module state (tstate->interp->warnings)
without going through the module object, like PyErr_WarnFormat().
----------
nosy: +vstinner
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue39796>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
