父对象

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 的一部分（参见 PEP 384 – 定义稳定 ABI）。因此，将 tp_print 字段从 printfunc（一个函数指针）更改为 Py_ssize_t 应该不会有问题，即使这改变了 PyTypeObject 结构的内存布局。此外，在所有通常构建二进制文件的系统（Windows、Linux、macOS）上，printfunc 和 Py_ssize_t 的大小相同，因此二进制兼容性问题根本不会出现。

检查 __objclass__

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

自身切片

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

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

此过程称为“self 切片”，如果 cr_self 为 NULL 且设置了 CCALL_SELFARG，则称函数具有 self 切片。

请注意，具有 self 切片的 CCALL_NOARGS 函数实际上有一个参数，即 self。类似地，具有 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__。这与 self 切片 无关：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)：使用位置参数args和关键字参数kwds调用func（kwds可以为 NULL）。此函数旨在放置在tp_call槽中。
• PyObject *PyCCall_FastCall(PyObject *func, PyObject *const *args, Py_ssize_t nargs, PyObject *kwds)：使用由args[0]、…、args[nargs-1]给出的nargs个位置参数调用func。参数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的简写。

通用获取器，旨在放入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__属性。

性能分析

仅当调用builtin_function_or_method或method_descriptor的实际实例时，才会生成概要分析事件c_call、c_return和c_exception。这样做是为了简单起见，也为了向后兼容（这样概要分析函数就不会接收它无法识别的对象）。在未来的 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）。