父级

cc_parent 字段（例如通过 Python 代码中的 __parent__ 或 __objclass__ 描述符访问）可以是任何 Python 对象，也可以是 NULL。自定义类可以自由地将 cc_parent 设置为它们想要的任何值。仅当设置了 CCALL_OBJCLASS 标志时，C 调用协议才使用它。

对于扩展类型的方法，cc_parent 指向定义方法的类（这可能是 type(self) 的超类）。目前，从方法的代码中检索此信息并非易事。将来，这可以用于通过定义类访问模块状态。有关详细信息，请参阅 PEP 573 的原理。

当设置了 CCALL_OBJCLASS 标志（对于扩展类型的方法将是这种情况）时，cc_parent 用于类型检查，如下所示

>>> list.append({}, "x")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: descriptor 'append' requires a 'list' object but received a 'dict'

对于模块的函数，cc_parent 设置为模块。目前，这与 __self__ 完全相同。然而，将 __self__ 用于模块是当前实现的一个怪癖：将来，我们希望允许函数以正常方式使用 __self__ 来实现方法。此类函数仍然可以使用 cc_parent 来引用模块。

父级通常也用于实现 __qualname__。新的 C API 函数 PyCCall_GenericGetQualname() 正是这样做的。

使用 tp_print

我们建议用 tp_ccalloffset 替换现有的未使用字段 tp_print。由于 Py_TPFLAGS_HAVE_CCALL 将不会添加到 Py_TPFLAGS_DEFAULT 中，这确保了对设置 tp_print 的现有扩展模块的完全向后兼容性。这也意味着我们可以要求在指定 Py_TPFLAGS_HAVE_CCALL 时 tp_ccalloffset 是一个有效偏移量：我们不需要检查 tp_ccalloffset != 0。在未来的 Python 版本中，我们可能会决定 tp_print 无条件地成为 tp_ccalloffset，删除 Py_TPFLAGS_HAVE_CCALL 标志，并转而检查 tp_ccalloffset != 0。

注意：PyTypeObject 的精确布局不是 稳定 ABI 的一部分。因此，将 tp_print 字段从 printfunc（函数指针）更改为 Py_ssize_t 不应该是一个问题，即使这会更改 PyTypeObject 结构的内存布局。此外，在所有通常构建二进制文件的系统（Windows、Linux、macOS）上，printfunc 和 Py_ssize_t 的大小相同，因此无论如何都不会出现二进制兼容性问题。

检查 __objclass__

如果设置了 CCALL_OBJCLASS 标志，并且 cr_self 为 NULL（对于扩展类型的未绑定方法就是这种情况），则进行类型检查：函数必须至少带一个位置参数，并且第一个参数（通常称为 self）必须是 cc_parent 的实例（cc_parent 必须是一个类）。否则，将引发 TypeError。

自身切片

如果 cr_self 不为 NULL，或者 cc_flags 中未设置 CCALL_SELFARG 标志，则作为 self 传递的参数就是 cr_self。

如果 cr_self 为 NULL 且设置了 CCALL_SELFARG 标志，则第一个位置参数将从 args 中删除，并作为 self 参数传递给 C 函数。实际上，第一个位置参数被视为 __self__。如果没有位置参数，则会引发 TypeError。

这个过程被称为“自身切片”，如果 cr_self 为 NULL 并且设置了 CCALL_SELFARG，则称函数具有自身切片。

请注意，具有自身切片的 CCALL_NOARGS 函数实际上有一个参数，即 self。类似地，具有自身切片的 CCALL_O 函数有两个参数。

描述符行为

支持 C 调用协议的类必须以特定方式实现描述符协议。

这是高效实现绑定方法所必需的：如果其他代码可以对 __get__ 的作用做出假设，它将启用否则不可能实现的优化。特别是，我们希望允许在绑定方法和非绑定方法之间共享 PyCCallDef 结构。我们还需要正确实现 _PyObject_GetMethod，该函数由 LOAD_METHOD/CALL_METHOD 优化使用。

首先，如果 func 支持 C 调用协议，则不得实现 func.__set__ 和 func.__delete__。

其次，func.__get__ 必须按如下方式执行

• 如果 cr_self 不为 NULL，则 __get__ 必须是无操作，即 func.__get__(obj, cls)(*args, **kwds) 的行为与 func(*args, **kwds) 完全相同。也允许完全不实现 __get__。
• 如果 cr_self 为 NULL，则 func.__get__(obj, cls)(*args, **kwds)（其中 obj 不为 None）必须等同于 func(obj, *args, **kwds)。特别是，在这种情况下必须实现 __get__。这与 自身切片无关：obj 可以作为 self 参数传递给 C 函数，也可以是第一个位置参数。
• 如果 cr_self 为 NULL，则 func.__get__(None, cls)(*args, **kwds) 必须等同于 func(*args, **kwds)。

对对象 func.__get__(obj, cls) 没有限制。例如，后者不需要实现 C 调用协议。我们只指定 func.__get__(obj, cls).__call__ 的作用。

对于完全不关心 __self__ 和 __get__ 的类，最简单的解决方案是分配 cr_self = Py_None（或任何其他非 NULL 值）。

__name__ 属性

C 调用协议要求函数具有 __name__ 属性，其类型为 str（而不是子类）。

此外，由 __name__ 返回的对象必须存储在某个地方；它不能是临时对象。这是必需的，因为 PyEval_GetFuncName 使用 __name__ 属性的借用引用（另请参见 [2]）。

通用 API 函数

本节列出了处理 C 调用协议的新公共 API 函数或宏。

• int PyCCall_Check(PyObject *op): 如果 op 实现了 C 调用协议，则返回 true。

以下所有函数和宏都适用于支持 C 调用协议的任何实例。换句话说，PyCCall_Check(func) 必须为 true。

• PyObject *PyCCall_Call(PyObject *func, PyObject *args, PyObject *kwds): 调用 func，使用位置参数 args 和关键字参数 kwds（kwds 可以为 NULL）。此函数旨在放入 tp_call 槽中。
• PyObject *PyCCall_FastCall(PyObject *func, PyObject *const *args, Py_ssize_t nargs, PyObject *kwds): 调用 func，使用 args[0]、…、args[nargs-1] 给出的 nargs 个位置参数。参数 kwds 可以为 NULL（无关键字参数），一个包含 name:value 项的字典，或者一个包含关键字名称的元组。在后一种情况下，关键字值存储在 args 数组中，从 args[nargs] 开始。

访问 PyCCallRoot 和 PyCCallDef 结构的宏

• const PyCCallRoot *PyCCall_CCALLROOT(PyObject *func): 指向 func 内部的 PyCCallRoot 结构。
• const PyCCallDef *PyCCall_CCALLDEF(PyObject *func): PyCCall_CCALLROOT(func)->cr_ccall 的简写。
• uint32_t PyCCall_FLAGS(PyObject *func): PyCCall_CCALLROOT(func)->cr_ccall->cc_flags 的简写。
• PyObject *PyCCall_SELF(PyOject *func): PyCCall_CCALLROOT(func)->cr_self 的简写。

通用 getter，旨在放入 tp_getset 数组

• PyObject *PyCCall_GenericGetParent(PyObject *func, void *closure): 返回 cc_parent。如果 cc_parent 为 NULL，则引发 AttributeError。
• PyObject *PyCCall_GenericGetQualname(PyObject *func, void *closure): 返回适合用作 __qualname__ 的字符串。如果可能，它会使用 cc_parent 的 __qualname__。它还使用 __name__ 属性。

分析

分析事件 c_call、c_return 和 c_exception 仅在调用 builtin_function_or_method 或 method_descriptor 的实际实例时生成。这是为了简化和向后兼容（以便配置文件函数不会接收到它无法识别的对象）。在未来的 PEP 中，我们可能会将 C 级分析扩展到实现 C 调用协议的任意类。

C API 函数

添加了以下函数（也添加到 稳定 ABI）

• PyObject * PyCFunction_ClsNew(PyTypeObject *cls, PyMethodDef *ml, PyObject *self, PyObject *module, PyObject *parent): 创建一个具有对象结构 PyCFunctionObject 和类 cls 的新对象。PyMethodDef 结构的条目用于构造新对象，但不存储指向 PyMethodDef 结构的指针。C 调用协议的标志根据 ml->ml_flags、self 和 parent 自动确定。

现有函数 PyCFunction_New、PyCFunction_NewEx 和 PyDescr_NewMethod 都是通过 PyCFunction_ClsNew 实现的。

未文档化的函数 PyCFunction_GetFlags 和 PyCFunction_GET_FLAGS 已弃用。它们仍然通过将原始 METH_... 标志存储在 cc_flags 中的位域中来人为支持。尽管 PyCFunction_GetFlags 在技术上是 稳定 ABI 的一部分，但它极不可能以这种方式使用：首先，它甚至没有文档。其次，标志 METH_FASTCALL 不是稳定 ABI 的一部分，但它非常常见（因为 Argument Clinic）。因此，如果不能支持 METH_FASTCALL，很难想象 PyCFunction_GetFlags 的用例。事实上，PyCFunction_GET_FLAGS 和 PyCFunction_GetFlags 在 CPython 的 Objects/call.c 之外根本没有使用，这进一步表明这些函数不是特别有用。

为什么这比 PEP 575 更好？

PEP 575 的主要抱怨之一是它将功能（调用和内省协议）与类层次结构耦合：一个类只有在其是 base_function 的子类时才能从新功能中受益。对于现有类来说，这可能很困难，因为它们可能对 C 对象结构的布局有其他限制，这些限制来自现有基类或实现细节。例如，functools.lru_cache 无法按原样实现 PEP 575。

它还使实现复杂化，正是因为需要在实现细节和类层次结构中进行更改。

当前的 PEP 没有这些问题。

为什么将函数指针存储在实例中？

调用对象所需的实际信息存储在实例中（在 PyCCallDef 结构中），而不是类中。这与 tp_call 槽或早期尝试实现 tp_fastcall 槽不同 [1]。

主要用例是内置函数和方法。对于这些，要调用的 C 函数确实取决于实例。

请注意，当前协议使得支持所有实例都调用同一个 C 函数的情况变得容易：只需为每个实例使用一个静态 PyCCallDef 结构。

为什么选择 CCALL_OBJCLASS？

标志 CCALL_OBJCLASS 旨在支持各种需要检查 self 参数的类的情况，例如

>>> list.append({}, None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: append() requires a 'list' object but received a 'dict'

>>> list.__len__({})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: descriptor '__len__' requires a 'list' object but received a 'dict'

>>> float.__dict__["fromhex"](list, "0xff")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: descriptor 'fromhex' for type 'float' doesn't apply to type 'list'

在参考实现中，只有第一个使用新代码。其他示例表明，此类检查出现在多个位置，因此添加对它们的通用支持是合理的。

为什么选择 CCALL_SELFARG？

标志 CCALL_SELFARG 和自身切片的概念是支持方法所必需的：C 函数不应关心它是作为未绑定方法还是绑定方法调用。在这两种情况下，都应该有一个 self 参数，而这正是未绑定方法调用的第一个位置参数。

例如，list.append 是一个 METH_O 方法。调用 list.append([], 42) 和 [].append(42) 都应该转换为 C 调用 list_append([], 42)。

由于建议的 C 调用协议，我们可以以一种方式支持这一点，使得未绑定方法和绑定方法共享一个 PyCCallDef 结构（设置了 CCALL_SELFARG 标志）。

因此，CCALL_SELFARG 有两个优点：调用方法没有额外的间接层，并且构造绑定方法不需要设置 PyCCallDef 结构。

另一个小优点是，我们可以使 Python 方法和内置方法之间错误调用签名的错误消息更加统一。在以下示例中，Python 不确定方法是接受 1 个参数还是 2 个参数

>>> class List(list):
...     def myappend(self, item):
...         self.append(item)
>>> List().myappend(1, 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: myappend() takes 2 positional arguments but 3 were given
>>> List().append(1, 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: append() takes exactly one argument (2 given)

目前 PyCFunction_Call 无法知道用户可见参数的实际数量，因为它在运行时无法区分函数（没有 self 参数）和绑定方法（有 self 参数）。CCALL_SELFARG 标志明确了这种差异。

为什么选择 CCALL_DEFARG？

标志 CCALL_DEFARG 允许被调用者访问 PyCCallDef *。这有各种用例

1. 被调用者可以使用 cc_parent 字段，这对于 PEP 573 非常有用。
2. 应用程序可以自由地用用户定义字段扩展 PyCCallDef 结构，然后可以类似地访问这些字段。
3. 在 PyCCallDef 结构是对象结构一部分的情况下（例如 PyCFunctionObject），可以从 PyCCallDef 指针中减去适当的偏移量，以获得指向定义该 PyCCallDef 的可调用对象的指针。

此 PEP 的早期版本定义了一个标志 CCALL_FUNCARG 而不是 CCALL_DEFARG，它会将可调用对象传递给被调用者。这有类似的用例，但对于绑定方法存在一些歧义：”可调用对象”应该是绑定方法对象还是方法包装的原始函数？通过传递 PyCCallDef *，这种歧义就消失了，因为绑定方法使用被包装函数的 PyCCallDef *。

替换 tp_print

我们将 tp_print 改作 tp_ccalloffset，因为这使得外部项目更容易将 C 调用协议反向移植到更早的 Python 版本。特别是，Cython 项目对此表现出兴趣（参见 https://mail.python.org/pipermail/python-dev/2018-June/153927.html）。