STINNER Victor <vstin...@python.org> added the comment:
> Why not do so by reverting the change that caused it? Making PyInterpreterState structure private was motivated by the subinterpreters work but also by the work on cleaning the C API. Over time, PyInterpreterState became more and more complex because many other structures have been moved there. For example, the GIL, GC state, warnings state, parser state, etc. I would really avoid exposing the GIL state in the C API since it uses the "pycore_atomic.h" header which caused a *lot* of compiler errors in the past. Most errors were on including the header file, even if the C extension didn't use any atomic variable. I'm really happy that we managed to move atomic variables into the internal C API: we got less error coming from that. I'm strongly opposed to move PyInterpreterState structure back into the Include/cpython/ C API. That would be a big mistake for various reasons. Even in CPython, pycore_pystate.h is causing a lot of troubles since PyInterpreterState became very complex. Example in posixmodule.c: --- #include "Python.h" #ifdef MS_WINDOWS /* include <windows.h> early to avoid conflict with pycore_condvar.h: #define WIN32_LEAN_AND_MEAN #include <windows.h> FSCTL_GET_REPARSE_POINT is not exported with WIN32_LEAN_AND_MEAN. */ # include <windows.h> #endif #include "pycore_ceval.h" /* _PyEval_ReInitThreads() */ #include "pycore_import.h" /* _PyImport_ReInitLock() */ #include "pycore_pystate.h" /* _PyRuntime */ --- pycore_condvar.h is used by the GIL state. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38500> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com