1 ####################################### 2 # C Globals and CPython Runtime State. 3 4 CPython's C code makes extensive use of global variables. Each global 5 falls into one of several categories: 6 7 * (effectively) constants (incl. static types) 8 * globals used exclusively in main or in the REPL 9 * freelists, caches, and counters 10 * process-global state 11 * module state 12 * Python runtime state 13 14 The ignored-globals.txt file is organized similarly. Of the different 15 categories, the last two are problematic and generally should not exist 16 in the codebase. 17 18 Globals that hold module state (i.e. in Modules/*.c) cause problems 19 when multiple interpreters are in use. For more info, see PEP 3121, 20 which addresses the situation for extension modules in general. 21 22 Globals in the last category should be avoided as well. The problem 23 isn't with the Python runtime having state. Rather, the problem is with 24 that state being spread throughout the codebase in dozens of individual 25 globals. Unlike the other globals, the runtime state represents a set 26 of values that are constantly shifting in a complex way. When they are 27 spread out it's harder to get a clear picture of what the runtime 28 involves. Furthermore, when they are spread out it complicates efforts 29 that change the runtime. 30 31 Consequently, the globals for Python's runtime state have been 32 consolidated under a single top-level _PyRuntime global. No new globals 33 should be added for runtime state. Instead, they should be added to 34 _PyRuntimeState or one of its sub-structs. The check-c-globals script 35 should be run to ensure that no new globals have been added: 36 37 python3 Tools/c-globals/check-c-globals.py 38 39 If it reports any globals then they should be resolved. If the globals 40 are runtime state then they should be folded into _PyRuntimeState. 41 Otherwise they should be added to ignored-globals.txt. 42
