STINNER Victor <[email protected]> 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 <[email protected]>
<https://bugs.python.org/issue38500>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
