@@ -7,75 +7,6 @@ extern "C" {
7
7
#include <stdbool.h>
8
8
#include <stddef.h>
9
9
10
- /* Starting in CPython 3.11, CPython separates the frame state between the
11
- * full frame objects exposed by the Python and C runtime state introspection
12
- * APIs, and internal lighter weight interpreter frames, which are simple C
13
- * structures owned by either the interpreter eval loop (while executing
14
- * ordinary functions), by a generator or coroutine object (for frames that
15
- * are able to be suspended), or by their corresponding full frame object (if
16
- * a state instrospection API has been invoked and the full frame object has
17
- * taken responsibility for the lifecycle of the interpreter frame).
18
- *
19
- * This split storage eliminates a lot of allocation and deallocation of full
20
- * Python objects during code execution, providing a significant speed gain
21
- * over the previous approach of using full Python objects for both
22
- * introspection and code execution.
23
- *
24
- * Struct names:
25
- *
26
- * * PyFrameObject: the full Python frame object
27
- * * _PyInterpreterFrame: the lightweight frame struct used by the eval loop
28
- * * _PyCFrame: a struct that lives on the C stack and allows Python level
29
- * recursive evaluation to be decoupled from recursive C level invocation
30
- * of the bytecode eval loop
31
- * * See pystate.h for more details on this struct
32
- *
33
- * Field naming conventions:
34
- *
35
- * * full frame object fields have an "f_*" (or "_f_*") prefix
36
- * * new interpreter frame fields have no prefix
37
- * * Several interpreter frame fields have the "f_*" prefix as a result of
38
- * trying to keep diffs as small as was feasible when splitting the original
39
- * frame struct definition in two. The following are all interpreter frame
40
- * fields, NOT full frame object fields:
41
- * * f_func
42
- * * f_globals
43
- * * f_builtins
44
- * * f_locals
45
- * * f_code
46
- * * f_lasti
47
- * * f_state
48
- * * Renaming those fields was considered but ultimately deemed too disruptive
49
- * to key third party projects that were trying to keep up with the Python
50
- * 3.11 code evaluation changes during the alpha release cycle
51
- * (see bpo-44800 for details)
52
- *
53
- * Naming conventions for local variables, function parameters and fields in other structs:
54
- *
55
- * * "frame" and "f" may refer to either full frame objects or interpreter frames
56
- * * the context of use or the field naming conventions usually make the
57
- * type being referenced unambiguous in code reviews
58
- * * the following alternative names are used when more clarity is needed:
59
- * * full frame objects: "frame_obj" (and variants like "frameobj" or "fobj")
60
- * * interpreter frame structs: "frame_data" or "iframe"
61
- * * "current frame" should NOT be abbreviated as "cframe", as the latter now
62
- * typically refers to _PyCFrame structs
63
- *
64
- * Function/macro parameter types:
65
- *
66
- * * "PyFrame_*" functions and other public C API functions that relate to
67
- * frames accept full frame object pointers
68
- * * "_PyFrame_*" functions and other private C API functions that relate to
69
- * frames accept either full frame object or interpreter frame pointers.
70
- * Check the specific function signatures for details.
71
- *
72
- * Function return types:
73
- *
74
- * * Public C API functions will only ever return full frame object pointers
75
- * * Private C API functions with an underscore prefix may return interpreter
76
- * frame pointers instead. Check the specific function signatures for details.
77
- */
78
-
79
10
struct _frame {
80
11
PyObject_HEAD
81
12
PyFrameObject * f_back ; /* previous frame, or NULL */
0 commit comments