1 files changed, 49 insertions, 1 deletions
diff --git a/Include/internal/pycore_code.h b/Include/internal/pycore_code.h
index f1e89d9..dab6c34 100644
--- a/Include/internal/pycore_code.h
+++ b/Include/internal/pycore_code.h
@@ -3,7 +3,8 @@
 #ifdef __cplusplus
 extern "C" {
 #endif
- 
+
+
 typedef struct {
     PyObject *ptr;  /* Cached pointer (borrowed reference) */
     uint64_t globals_ver;  /* ma_version of global dict */
@@ -24,7 +25,54 @@ struct _PyOpcache {
     char optimized;
 };
 
+
+struct _PyCodeConstructor {
+    /* metadata */
+    PyObject *filename;
+    PyObject *name;
+    int flags;
+
+    /* the code */
+    PyObject *code;
+    int firstlineno;
+    PyObject *linetable;
+
+    /* used by the code */
+    PyObject *consts;
+    PyObject *names;
+
+    /* mapping frame offsets to information */
+    PyObject *varnames;
+    PyObject *cellvars;
+    PyObject *freevars;
+
+    /* args (within varnames) */
+    int argcount;
+    int posonlyargcount;
+    int kwonlyargcount;
+
+    /* needed to create the frame */
+    int stacksize;
+
+    /* used by the eval loop */
+    PyObject *exceptiontable;
+};
+
+// Using an "arguments struct" like this is helpful for maintainability
+// in a case such as this with many parameters.  It does bear a risk:
+// if the struct changes and callers are not updated properly then the
+// compiler will not catch problems (like a missing argument).  This can
+// cause hard-to-debug problems.  The risk is mitigated by the use of
+// check_code() in codeobject.c.  However, we may decide to switch
+// back to a regular function signature.  Regardless, this approach
+// wouldn't be appropriate if this weren't a strictly internal API.
+// (See the comments in https://github.com/python/cpython/pull/26258.)
+PyAPI_FUNC(int) _PyCode_Validate(struct _PyCodeConstructor *);
+PyAPI_FUNC(PyCodeObject *) _PyCode_New(struct _PyCodeConstructor *);
+
+
 /* Private API */
+
 int _PyCode_InitOpcache(PyCodeObject *co);