扩展 PyCodeObject

一个字段将被添加到 PyCodeObject 结构 [3] 中

typedef struct {
   ...
   void *co_extra;  /* "Scratch space" for the code object. */
} PyCodeObject;

co_extra 默认将为 NULL，仅在需要时填充。存储在该字段中的值预计不是代码对象正常运行所必需的，因此字段数据的丢失是可接受的。

已引入一个私有 API 来处理该字段

PyAPI_FUNC(Py_ssize_t) _PyEval_RequestCodeExtraIndex(freefunc);
PyAPI_FUNC(int) _PyCode_GetExtra(PyObject *code, Py_ssize_t index,
                                 void **extra);
PyAPI_FUNC(int) _PyCode_SetExtra(PyObject *code, Py_ssize_t index,
                                 void *extra);

该字段的用户预计会调用 _PyEval_RequestCodeExtraIndex() 以接收（应视为）一个不透明的索引值，用于向 co-extra 添加数据。通过该索引，用户可以使用 _PyCode_SetExtra() 设置数据，稍后使用 _PyCode_GetExtra() 检索数据。该 API 被有意列为私有，以表明 Python 版本之间该 API 没有语义保证。

曾考虑使用列表和元组，但发现性能较差，考虑到主要用例是 JIT，性能因素使得使用自定义结构而不是 Python 对象更具优势。

也曾考虑使用字典，但再次强调，性能更为重要。虽然字典在查找数据时会有固定的开销，但在数据结构中存储单个对象的常见情况下，元组具有更好的性能特性（即，迭代长度为 1 的元组比在字典中哈希和查找对象的开销更快）。

扩展 PyInterpreterState

帧评估函数的入口点是每个解释器

// Same type signature as PyEval_EvalFrameEx().
typedef PyObject* (*_PyFrameEvalFunction)(PyFrameObject*, int);

typedef struct {
    ...
    _PyFrameEvalFunction eval_frame;
} PyInterpreterState;

默认情况下，eval_frame 字段将初始化为一个函数指针，该函数指针表示 PyEval_EvalFrameEx() 当前是什么（称为 _PyEval_EvalFrameDefault()，本 PEP 稍后讨论）。然后，第三方代码可以设置自己的帧评估函数来控制 Python 代码的执行。可以使用指针比较来检测该字段是否设置为 _PyEval_EvalFrameDefault()，从而尚未被修改。

对 Python/ceval.c 的更改

PyEval_EvalFrameEx() [5] 的当前形式将被重命名为 _PyEval_EvalFrameDefault()。新的 PyEval_EvalFrameEx() 将变为

PyObject *
PyEval_EvalFrameEx(PyFrameObject *frame, int throwflag)
{
    PyThreadState *tstate = PyThreadState_GET();
    return tstate->interp->eval_frame(frame, throwflag);
}

这允许第三方代码直接插入 Python 代码执行路径，同时向后兼容已使用现有 C API 的代码。

更新 python-gdb.py

用于 GDB 中 Python 支持的生成的 python-gdb.py 文件对 PyEval_EvalFrameEx() 做出了一些硬编码假设，例如局部变量的名称。它需要更新以适应提议的更改。

CPython 的 JIT

def eval_frame(frame, throw_flag):
    pyjion_code = frame.code.co_extra
    if not pyjion_code:
        frame.code.co_extra = PyjionJittedCode()
    elif not pyjion_code.jit_failed:
        if not pyjion_code.jit_code:
            return pyjion_code.eval(pyjion_code.jit_code, frame)
        elif pyjion_code.exec_count > 20_000:
            if jit_compile(frame):
                return pyjion_code.eval(pyjion_code.jit_code, frame)
            else:
                pyjion_code.jit_failed = True
    pyjion_code.exec_count += 1
    return _PyEval_EvalFrameDefault(frame, throw_flag)

调试

在与 Visual Studio 的 Python 工具团队（PTVS）[12] 的对话中，他们认为这些 API 更改对于实现更高性能的调试会很有用。如 原理 部分所述，此 API 将允许仅在需要调试功能的帧中打开调试功能。这可以允许跳过 sys.settrace() 通常提供的信息，甚至可以进一步动态重写字节码，以便在执行之前注入例如字节码中的断点。

事实证明，Google 在内部也提供了非常相似的 API。它已被用于高性能调试目的。

允许 eval_frame 为 NULL

目前，帧评估函数被期望始终设置。它也可以很容易地简单地默认为 NULL，这将表示使用 _PyEval_EvalFrameDefault()。当前不特殊处理该字段的提议似乎最直接，但它确实要求该字段不会意外被清除，否则可能会发生崩溃。

一个 JIT 特定的 C API

最初，本 PEP 打算提出一个更庞大、更具 JIT 特性的 API 更改。然而，在征求 Numba 团队 [6] 的反馈后，很明显该 API 过于庞大。我们意识到，真正需要的只是提供一个跳板函数来处理已 JIT 编译的 Python 代码的执行，以及一种将编译后的机器代码与其他关键数据附加到相应 Python 代码对象的方法。一旦证明在不损失功能或性能的同时最小化所需的 API 更改，该提案就更改为当前形式。

co_extra 是否需要？

在 PyCon US 2016 讨论此 PEP 时，一些核心开发人员表达了他们对 co_extra 字段使代码对象可变的担忧。他们的想法似乎是，在代码对象创建后被修改的字段使该对象看起来是可变的，即使代码对象的其他方面没有改变。

本 PEP 认为 co_extra 字段不会改变代码对象是不可变的事实。本 PEP 中指定的该字段不包含使代码对象可用的所需信息，使其更像一个缓存字段。它可以被视为类似于字符串对象内部的 UTF-8 缓存；尽管字符串有一个有条件设置的字段，但它们仍然被认为是不可变的。

还对 JIT 工作负载不可用的字段进行了性能测量。当使用 C++ 的无序映射或 Python 的字典将代码对象与 JIT 特定数据对象关联时，丢失该字段被认为对性能而言代价太高。