STINNER Victor <vstin...@python.org> 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 <rep...@bugs.python.org> <https://bugs.python.org/issue39796> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com