|
3 | 3 |
|
4 | 4 | #include"Python.h" |
5 | 5 | #include"pycore_ceval.h"// _PyEval_BuiltinsFromGlobals() |
6 | | -#include"pycore_code.h"// _Py_next_func_version |
7 | 6 | #include"pycore_object.h"// _PyObject_GC_UNTRACK() |
8 | 7 | #include"pycore_pyerrors.h"// _PyErr_Occurred() |
9 | 8 |
|
@@ -252,11 +251,9 @@ When the function version is 0, the `CALL` bytecode is not specialized. |
252 | 251 | Code object versions |
253 | 252 | -------------------- |
254 | 253 |
|
255 | | -So where to code objects get their `co_version`? There is a single |
256 | | -static global counter, `_Py_next_func_version`. This is initialized in |
257 | | -the generated (!) file `Python/deepfreeze/deepfreeze.c`, to 1 plus the |
258 | | -number of deep-frozen function objects in that file. |
259 | | -(In `_bootstrap_python.c` and `freeze_module.c` it is initialized to 1.) |
| 254 | +So where to code objects get their `co_version`? |
| 255 | +There is a per-interpreter counter, `next_func_version`. |
| 256 | +This is initialized to 1 when the interpreter is created. |
260 | 257 |
|
261 | 258 | Code objects get a new `co_version` allocated from this counter upon |
262 | 259 | creation. Since code objects are nominally immutable, `co_version` can |
|