Author vstinner
Recipients Mark.Shannon, brett.cannon, dino.viehland, eric.snow, fabioz, gregory.p.smith, lukasz.langa, phsilva, vstinner
Date 2020-03-12.12:50:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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"
   /* 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>

#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.
Date User Action Args
2020-03-12 12:50:44vstinnersetrecipients: + vstinner, brett.cannon, gregory.p.smith, fabioz, phsilva, dino.viehland, lukasz.langa, Mark.Shannon, eric.snow
2020-03-12 12:50:44vstinnersetmessageid: <>
2020-03-12 12:50:44vstinnerlinkissue38500 messages
2020-03-12 12:50:44vstinnercreate