概述¶

Python 的应用编程接口（API）使得 C 和 C++ 程序员可以在多个层级上访问 Python 解释器。该 API 在 C++ 中同样可用，但为简化描述，通常将其称为 Python/C API。使用 Python/C API 有两个基本的理由。第一个理由是为了特定目的而编写 扩展模块；它们是扩展 Python 解释器功能的 C 模块。这可能是最常见的使用场景。第二个理由是将 Python 用作更大规模应用的组件；这种技巧通常被称为在一个应用中 embedding Python。

编写扩展模块的过程相对来说更易于理解，可以通过“菜谱”的形式分步骤介绍。使用某些工具可在一定程度上自动化这一过程。虽然人们在其他应用中嵌入 Python 的做法早已有之，但嵌入 Python 的过程没有编写扩展模块那样方便直观。

许多 API 函数在你嵌入或是扩展 Python 这两种场景下都能发挥作用；此外，大多数嵌入 Python 的应用程序也需要提供自定义扩展，因此在尝试在实际应用中嵌入 Python 之前先熟悉编写扩展应该会是个好主意。

代码标准¶

如果你想要编写可包含于 CPython 的 C 代码，你必须遵循在 PEP 7 中定义的指导原则和标准。这些指导原则适用于任何你所要扩展的 Python 版本。在编写你自己的第三方扩展模块时可以不必遵循这些规范，除非你准备在日后向 Python 贡献这些模块。

包含文件¶

使用 Python/C API 所需要的全部函数、类型和宏定义可通过下面这行语句包含到你的代码之中：

#define PY_SSIZE_T_CLEAN
#include <Python.h>

这意味着包含以下标准头文件：<stdio.h>，<string.h>，<errno.h>，<limits.h>，<assert.h> 和 <stdlib.h>（如果可用）。

注解

由于 Python 可能会定义一些能在某些系统上影响标准头文件的预处理器定义，因此在包含任何标准头文件之前，你必须先包含 Python.h。

推荐总是在 Python.h 前定义 PY_SSIZE_T_CLEAN 。查看解析参数并构建值变量来了解这个宏的更多内容。

Python.h 所定义的全部用户可见名称（由包含的标准头文件所定义的除外）都带有前缀 Py 或者 _Py。以 _Py 打头的名称是供 Python 实现内部使用的，不应被扩展编写者使用。结构成员名称没有保留前缀。

注解

用户代码永远不应该定义以 Py 或 _Py 开头的名称。这会使读者感到困惑，并危及用户代码对未来Python版本的可移植性，这些版本可能会定义以这些前缀之一开头的其他名称。

头文件通常会与 Python 一起安装。在 Unix 上，它们位于以下目录：prefix/include/pythonversion/ 和 exec_prefix/include/pythonversion/，其中 prefix 和 exec_prefix 是由向 Python 的 configure 脚本传入的对应形参所定义，而 version 则为 '%d.%d' % sys.version_info[:2]。在 Windows 上，头文件安装于 prefix/include，其中 prefix 是向安装程序指定的安装目录。

要包含头文件，请将两个目录（如果不同）都放到你所用编译器的包含搜索路径中。请不要将父目录放入搜索路径然后使用 #include <pythonX.Y/Python.h>；这将使得多平台编译不可用，因为 prefix 下平台无关的头文件需要包含来自 exec_prefix 下特定平台的头文件。

C++ 用户应该注意，尽管 API 是完全使用 C 来定义的，但头文件正确地将入口点声明为 extern "C"，因此 API 在 C++ 中使用此 API 不必再做任何特殊处理。

有用的宏¶

Python 头文件中定义了一些有用的宏。许多是在靠近它们被使用的地方定义的（例如 Py_RETURN_NONE）。其他更为通用的则定义在这里。这里所显示的并不是一个完整的列表。

Py_UNREACHABLE()¶

这个可以在你有一个设计上无法到达的代码路径时使用。例如，当一个 switch 语句中所有可能的值都已被 case 子句覆盖了，就可将其用在 default: 子句中。当你非常想在某个位置放一个 assert(0) 或 abort() 调用时也可以用这个。

在 release 模式下，该宏帮助编译器优化代码，并避免发出不可到达代码的警告。例如，在 GCC 的 release 模式下，该宏使用 __builtin_unreachable() 实现。

Py_UNREACHABLE() 的一个用法是调用一个不会返回，但却没有声明 _Py_NO_RETURN 的函数之后。

如果一个代码路径不太可能是正常代码，但在特殊情况下可以到达，就不能使用该宏。例如，在低内存条件下，或者一个系统调用返回超出预期范围值，诸如此类，最好将错误报告给调用者。如果无法将错误报告给调用者，可以使用 Py_FatalError() 。

3.7 新版功能.

Py_ABS(x)¶: 返回 x 的绝对值。

3.3 新版功能.

Py_MIN(x, y)¶: 返回 x 和 y 当中的最小值。

3.3 新版功能.

Py_MAX(x, y)¶: 返回 x 和 y 当中的最大值。

3.3 新版功能.

Py_STRINGIFY(x)¶: 将 x 转换为 C 字符串。例如 Py_STRINGIFY(123) 返回 "123"。

3.4 新版功能.

Py_MEMBER_SIZE(type, member)¶: 返回结构 (type) member 的大小，以字节表示。

3.6 新版功能.

Py_CHARMASK(c)¶: 参数必须为 [-128, 127] 或 [0, 255] 范围内的字符或整数类型。这个宏将 c 强制转换为 unsigned char 返回。

Py_GETENV(s)¶: 与 getenv(s) 类似，但是如果命令行上传递了 -E ，则返回 NULL （即如果设置了 Py_IgnoreEnvironmentFlag ）。

Py_UNUSED(arg)¶: 用于函数定义中未使用的参数，从而消除编译器警告。例如： int func(int a, int Py_UNUSED(b)) { return a; } 。

3.4 新版功能.

Py_DEPRECATED(version)¶

弃用声明。该宏必须放置在符号名称前。

示例:

Py_DEPRECATED(3.8) PyAPI_FUNC(int) Py_OldFunction(void);

在 3.8 版更改: 添加了 MSVC 支持。

PyDoc_STRVAR(name, str)¶

创建一个可以在文档字符串中使用的，名字为 name 的变量。如果不和文档字符串一起构建 Python，该值将为空。

如 PEP 7 所述，使用 PyDoc_STRVAR 作为文档字符串，以支持不和文档字符串一起构建 Python 的情况。

示例:

PyDoc_STRVAR(pop_doc, "Remove and return the rightmost element.");

static PyMethodDef deque_methods[] = {
    // ...
    {"pop", (PyCFunction)deque_pop, METH_NOARGS, pop_doc},
    // ...
}

PyDoc_STR(str)¶

为给定的字符串输入创建一个文档字符串，或者当文档字符串被禁用时，创建一个空字符串。

如 PEP 7 所述，使用 PyDoc_STR 指定文档字符串，以支持不和文档字符串一起构建 Python 的情况。

示例:

static PyMethodDef pysqlite_row_methods[] = {
    {"keys", (PyCFunction)pysqlite_row_keys, METH_NOARGS,
        PyDoc_STR("Returns the keys of the row.")},
    {NULL, NULL}
};

对象、类型和引用计数¶

多数 Python/C API 有一个或多个参数，以及一个 PyObject* 类型的返回值。这种类型是指向任意 Python 对象的不透明数据类型的指针。所有 Python 对象类型在大多数情况下都被 Python 语言由相同的方式处理（例如，赋值，作用域规则，和参数传递），因此将它们由单个 C 类型表示才合适。几乎所有 Python 对象存放在堆中：你不能声明一个类型为 PyObject 的自动或静态的变量，只能声明类型为 PyObject* 的指针。type 对象是唯一的例外，因为它们永远不能被释放，所以它们通常是静态的 PyTypeObject 对象。

所有 Python 对象（甚至 Python 整数）都有一个 type 和一个 reference count。对象的类型确定它是什么类型的对象（例如整数、列表或用户定义函数；还有更多，如标准类型层级结构中所述）。对于每个众所周知的类型，都有一个宏来检查对象是否属于该类型；例如，当（且仅当） a 所指的对象是 Python 列表时 PyList_Check(a) 为真。

引用计数¶

引用计数非常重要，因为现代计算机内存（通常十分）有限；它计算有多少不同的地方引用同一个对象。这样的地方可以是某个对象，或者是某个全局（或静态）C 变量，亦或是某个 C 函数的局部变量。当一个对象的引用计数变为 0，释放该对象。如果这个已释放的对象包含其它对象的引用计数，则递减这些对象的引用计数。如果这些对象的引用计数减少为零，则可以依次释放这些对象，依此类推。（这里有一个很明显的问题——对象之间相互引用；目前，解决方案是“不要那样做”。）

总是显式操作引用计数。通常的方法是使用宏 Py_INCREF() 来增加一个对象的引用计数，使用宏 Py_DECREF() 来减少一个对象的引用计数。宏 Py_DECREF() 必须检查引用计数是否为零，然后调用对象的释放器，因此它比 incref 宏复杂得多。释放器是一个包含在对象类型结构中的函数指针。如果对象是复合对象类型（例如列表），则类型特定的释放器负责递减包含在对象中的其他对象的引用计数，并执行所需的终结。引用计数不会溢出，至少用与虚拟内存中不同内存位置一样多的位用于保存引用计数（即 sizeof(Py_ssize_t) >= sizeof(void*) ）。因此，引用计数递增是一个简单的操作。

没有必要为每个包含指向对象的指针的局部变量增加对象的引用计数。理论上，当变量指向对象时，对象的引用计数增加 1 ，当变量超出范围时，对象的引用计数减少 1 。但是，这两者相互抵消，所以最后引用计数没有改变。使用引用计数的唯一真正原因是只要我们的变量指向它，就可以防止对象被释放。如果知道至少有一个对该对象的其他引用存活时间至少和我们的变量一样长，则没必要临时增加引用计数。一个典型的情形是，对象作为参数从 Python 中传递给被调用的扩展模块中的 C 函数时，调用机制会保证在调用期间持有对所有参数的引用。

但是，有一个常见的陷阱是从列表中提取一个对象，并将其持有一段时间，而不增加其引用计数。某些操作可能会从列表中删除某个对象，减少其引用计数，并有可能重新分配这个对象。真正的危险是，这个看似无害的操作可能会调用任意 Python 代码——也许有一个代码路径允许控制流从 Py_DECREF() 回到用户，因此在复合对象上的操作都存在潜在的风险。

一个安全的方式是始终使用泛型操作（名称以 PyObject_ ， PyNumber_ ， PySequence_ 或 PyMapping_ 开头的函数）。这些操作总是增加它们返回的对象的引用计数。这让调用者有责任在获得结果后调用 Py_DECREF() 。习惯这种方式很简单。

引用计数细节¶

The reference count behavior of functions in the Python/C API is best explained in terms of ownership of references. Ownership pertains to references, never to objects (objects are not owned: they are always shared). "Owning a reference" means being responsible for calling Py_DECREF on it when the reference is no longer needed. Ownership can also be transferred, meaning that the code that receives ownership of the reference then becomes responsible for eventually decref'ing it by calling Py_DECREF() or Py_XDECREF() when it's no longer needed---or passing on this responsibility (usually to its caller). When a function passes ownership of a reference on to its caller, the caller is said to receive a new reference. When no ownership is transferred, the caller is said to borrow the reference. Nothing needs to be done for a borrowed reference.

相反地，当调用方函数传入一个对象的引用时，存在两种可能：该函数窃取了一个对象的引用，或是没有窃取。 窃取引用 意味着当你向一个函数传入引用时，该函数会假定它拥有该引用，而你将不再对它负有责任。

很少有函数会窃取引用；两个重要的例外是 PyList_SetItem() 和 PyTuple_SetItem()，它们会窃取对条目的引用（但不是条目所在的元组或列表！）。这些函数被设计为会窃取引用是因为在使用新创建的对象来填充元组或列表时有一个通常的惯例；例如，创建元组 (1, 2, "three") 的代码看起来可以是这样的（暂时不要管错误处理；下面会显示更好的代码编写方式）:

PyObject *t;

t = PyTuple_New(3);
PyTuple_SetItem(t, 0, PyLong_FromLong(1L));
PyTuple_SetItem(t, 1, PyLong_FromLong(2L));
PyTuple_SetItem(t, 2, PyUnicode_FromString("three"));

在这里，PyLong_FromLong() 返回了一个新的引用并且它立即被 PyTuple_SetItem() 所窃取。当你想要继续使用一个对象而对它的引用将被窃取时，请在调用窃取引用的函数之前使用 Py_INCREF() 来抓取另一个引用。

顺便提一下，PyTuple_SetItem() 是设置元组条目的唯一方式；PySequence_SetItem() 和 PyObject_SetItem() 会拒绝这样做因为元组是不可变数据类型。你应当只对你自己创建的元组使用 PyTuple_SetItem()。

等价于填充一个列表的代码可以使用 PyList_New() 和 PyList_SetItem() 来编写。

然而，在实践中，你很少会使用这些创建和填充元组或列表的方式。有一个通用的函数 Py_BuildValue() 可以根据 C 值来创建大多数常用对象，由一个 格式字符串 来指明。例如，上面的两个代码块可以用下面的代码来代替（还会负责错误检测）:

PyObject *tuple, *list;

tuple = Py_BuildValue("(iis)", 1, 2, "three");
list = Py_BuildValue("[iis]", 1, 2, "three");

使用 PyObject_SetItem() 等来处理那些你只是借入引用的条目是更为常见的，例如传给你正在编写的函数的参数。在这种情况下，他们对于引用计数的行为会更为理智，因为你不需要递增引用计数以便你可以将引用计数转出去（“让它被窃取”）。例如，这个函数将一个列表（实例上是任何可变序列）中的所有项设置为一个给定的条目:

int
set_all(PyObject *target, PyObject *item)
{
    Py_ssize_t i, n;

    n = PyObject_Length(target);
    if (n < 0)
        return -1;
    for (i = 0; i < n; i++) {
        PyObject *index = PyLong_FromSsize_t(i);
        if (!index)
            return -1;
        if (PyObject_SetItem(target, index, item) < 0) {
            Py_DECREF(index);
            return -1;
        }
        Py_DECREF(index);
    }
    return 0;
}

对于函数返回值的情况略有不同。虽然向大多数函数传递一个引用不会改变你对该引用的所有权责任，但许多返回一个引用的函数会给你该引用的所有权。原因很简单：在许多情况下，返回的对象是临时创建的，而你得到的引用是对该对象的唯一引用。因此，返回对象引用的通用函数，如 PyObject_GetItem() 和 PySequence_GetItem()，将总是返回一个新的引用（调用方将成为该引用的所有者）。

一个需要了解的重点在于你是否拥有一个由函数返回的引用只取决于你所调用的函数 --- 附带物 (作为参数传给函数的对象的类型) 不会带来额外影响！ 因此，如果你使用 PyList_GetItem() 从一个列表提取条目，你并不会拥有其引用 --- 但是如果你使用 PySequence_GetItem() (它恰好接受完全相同的参数) 从同一个列表获取同样的条目，你就会拥有一个对所返回对象的引用。

下面是说明你要如何编写一个函数来计算一个整数列表中条目的示例；一个是使用 PyList_GetItem()，而另一个是使用 PySequence_GetItem()。

long
sum_list(PyObject *list)
{
    Py_ssize_t i, n;
    long total = 0, value;
    PyObject *item;

    n = PyList_Size(list);
    if (n < 0)
        return -1; /* Not a list */
    for (i = 0; i < n; i++) {
        item = PyList_GetItem(list, i); /* Can't fail */
        if (!PyLong_Check(item)) continue; /* Skip non-integers */
        value = PyLong_AsLong(item);
        if (value == -1 && PyErr_Occurred())
            /* Integer too big to fit in a C long, bail out */
            return -1;
        total += value;
    }
    return total;
}

long
sum_sequence(PyObject *sequence)
{
    Py_ssize_t i, n;
    long total = 0, value;
    PyObject *item;
    n = PySequence_Length(sequence);
    if (n < 0)
        return -1; /* Has no length */
    for (i = 0; i < n; i++) {
        item = PySequence_GetItem(sequence, i);
        if (item == NULL)
            return -1; /* Not a sequence, or other failure */
        if (PyLong_Check(item)) {
            value = PyLong_AsLong(item);
            Py_DECREF(item);
            if (value == -1 && PyErr_Occurred())
                /* Integer too big to fit in a C long, bail out */
                return -1;
            total += value;
        }
        else {
            Py_DECREF(item); /* Discard reference ownership */
        }
    }
    return total;
}

类型¶

在 Python/C API 中扮演重要角色的其他数据类型很少；大多为简单 C 类型如 int, long, double 和 char*。有一些结构类型被用来描述用于列出模块导出的函数或者某个新对象类型的静态表，还有一个结构类型被用来描述复数的值。这些结构类型将与使用它们的函数一起讨论。

Py_ssize_t¶: 一个使得 sizeof(Py_ssize_t) == sizeof(size_t) 的有符号整数类型。 C99 没有直接定义这样的东西（size_t 是一个无符号整数类型）。请参阅 PEP 353 了解详情。 PY_SSIZE_T_MAX 是 Py_ssize_t 类型的最大正数值。

异常¶

Python程序员只需要处理特定需要处理的错误异常；未处理的异常会自动传递给调用者，然后传递给调用者的调用者，依此类推，直到他们到达顶级解释器，在那里将它们报告给用户并伴随堆栈回溯。

然而，对于 C 程序员来说，错误检查必须总是显式进行的。 Python/C API 中的所有函数都可以引发异常，除非在函数的文档中另外显式声明。一般来说，当一个函数遇到错误时，它会设置一个异常，丢弃它所拥有的任何对象引用，并返回一个错误标示。如果没有说明例外的文档，这个标示将为 NULL 或 -1，具体取决于函数的返回类型。有少量函数会返回一个布尔真/假结果值，其中假值表示错误。有极少的函数没有显式的错误标示或是具有不明确的返回值，并需要用 PyErr_Occurred() 来进行显式的检测。这些异常总是会被明确地记入文档中。

异常状态是在各个线程的存储中维护的（这相当于在一个无线程的应用中使用全局存储）。一个线程可以处在两种状态之一：异常已经发生，或者没有发生。函数 PyErr_Occurred() 可以被用来检查此状态：当异常发生时它将返回一个借入的异常类型对象的引用，在其他情况下则返回 NULL。有多个函数可以设置异常状态: PyErr_SetString() 是最常见的（尽管不是最通用的）设置异常状态的函数，而 PyErr_Clear() 可以清除异常状态。

完整的异常状态由三个对象组成 (它为都可以为 NULL): 异常类型、相应的异常值，以及回溯信息。这些对象的含义与 Python 中 sys.exc_info() 的结果相同；然而，它们并不是一样的：Python 对象代表由 Python try ... except 语句所处理的最后一个异常，而 C 层级的异常状态只在异常被传入到 C 函数或在它们之间传递时存在直至其到达 Python 字节码解释器的主事件循环，该事件循环会负责将其转移至 sys.exc_info() 等处。

请注意自 Python 1.5 开始，从 Python 代码访问异常状态的首选的、线程安全的方式是调用函数 sys.exc_info()，它将返回 Python 代码的分线程异常状态。此外，这两种访问异常状态的方式的语义都发生了变化因而捕获到异常的函数将保存并恢复其线程的异常状态以保留其调用方的异常状态。这将防止异常处理代码中由一个看起来很无辜的函数覆盖了正在处理的异常所造成的常见错误；它还减少了在回溯由栈帧所引用的对象的往往不被需要的生命其延长。

作为一般的原则，一个调用另一个函数来执行某些任务的函数应当检查被调用的函数是否引发了异常，并在引发异常时将异常状态传递给其调用方。它应当丢弃它所拥有的任何对象引用，并返回一个错误标示，但它不应设置另一个异常 --- 那会覆盖刚引发的异常，并丢失有关错误确切原因的重要信息。

一个检测异常并传递它们的简单例子在上面的 sum_sequence() 示例中进行了演示。这个例子恰好在检测到错误时不需要清理所拥有的任何引用。下面的示例函数演示了一些错误清理操作。首先，为了向你提示 Python 的优势，我们展示了等效的 Python 代码:

def incr_item(dict, key):
    try:
        item = dict[key]
    except KeyError:
        item = 0
    dict[key] = item + 1

下面是对应的闪耀荣光的 C 代码：

int
incr_item(PyObject *dict, PyObject *key)
{
    /* Objects all initialized to NULL for Py_XDECREF */
    PyObject *item = NULL, *const_one = NULL, *incremented_item = NULL;
    int rv = -1; /* Return value initialized to -1 (failure) */

    item = PyObject_GetItem(dict, key);
    if (item == NULL) {
        /* Handle KeyError only: */
        if (!PyErr_ExceptionMatches(PyExc_KeyError))
            goto error;

        /* Clear the error and use zero: */
        PyErr_Clear();
        item = PyLong_FromLong(0L);
        if (item == NULL)
            goto error;
    }
    const_one = PyLong_FromLong(1L);
    if (const_one == NULL)
        goto error;

    incremented_item = PyNumber_Add(item, const_one);
    if (incremented_item == NULL)
        goto error;

    if (PyObject_SetItem(dict, key, incremented_item) < 0)
        goto error;
    rv = 0; /* Success */
    /* Continue with cleanup code */

 error:
    /* Cleanup code, shared by success and failure path */

    /* Use Py_XDECREF() to ignore NULL references */
    Py_XDECREF(item);
    Py_XDECREF(const_one);
    Py_XDECREF(incremented_item);

    return rv; /* -1 for error, 0 for success */
}

这个例子代表了 C 语言中 goto 语句一种受到认可的用法！它说明了如何使用 PyErr_ExceptionMatches() 和 PyErr_Clear() 来处理特定的异常，以及如何使用 Py_XDECREF() 来处理可能为 NULL 的自有引用（注意名称中的 'X'；Py_DECREF() 在遇到 NULL 引用时将会崩溃）。重要的一点在于用来保存自有引用的变量要被初始化为 NULL 才能发挥作用；类似地，建议的返回值也要被初始化为 -1 (失败) 并且只有在最终执行的调用成功后才会被设置为成功。

嵌入Python¶

只有 Python 解释器的嵌入方（相对于扩展编写者而言）才需要担心的一项重要任务是它的初始化，可能还有它的最终化。解释器的大多数功能只有在解释器被初始化之后才能被使用。

基本的初始化函数是 Py_Initialize()。此函数将初始化已加载模块表，并创建基本模块 builtins, __main__ 和 sys。它还将初始化模块搜索路径 (sys.path)。

Py_Initialize() 不会设置 "脚本参数列表" (sys.argv)。如果随后将要执行的 Python 代码需要此变量，则必须在调用 Py_Initialize() 之后通过调用 PySys_SetArgvEx(argc, argv, updatepath) 来显式地设置它。

在大多数系统上（特别是 Unix 和 Windows，虽然在细节上有所不同），Py_Initialize() 将根据对标准 Python 解释器可执行文件的位置的最佳猜测来计算模块搜索路径，并设定 Python 库可在相对于 Python 解释器可执行文件的固定位置上找到。特别地，它将相对于在 shell 命令搜索路径 (环境变量 PATH) 上找到的名为 python 的可执行文件所在父目录中查找名为 lib/pythonX.Y 的目录。

举例来说，如果 Python 可执行文件位于 /usr/local/bin/python，它将假定库位于 /usr/local/lib/pythonX.Y。（实际上，这个特定路径还将成为“回退”位置，会在当无法在 PATH 中找到名为 python 的可执行文件时被使用。）用户可以通过设置环境变量 PYTHONHOME，或通过设置 PYTHONPATH 在标准路径之前插入额外的目录来覆盖此行为。

嵌入的应用程序可以通过在调用 Py_Initialize() 之前调用 Py_SetProgramName(file) 来改变搜索次序。请注意 PYTHONHOME 仍然会覆盖此设置并且 PYTHONPATH 仍然会被插入到标准路径之前。需要完全控制权的应用程序必须提供它自己的 Py_GetPath(), Py_GetPrefix(), Py_GetExecPrefix() 和 Py_GetProgramFullPath() 实现（这些函数均在 Modules/getpath.c 中定义）。

有时，还需要对 Python 进行“反初始化”。例如，应用程序可能想要重新启动 (再次调用 Py_Initialize()) 或者应用程序对 Python 的使用已经完成并想要释放 Python 所分配的内存。这可以通过调用 Py_FinalizeEx() 来实现。如果当前 Python 处于已初始化状态则 Py_IsInitialized() 函数将返回真值。有关这些函数的更多信息将在之后的章节中给出。请注意 Py_FinalizeEx() 不会释放所有由 Python 解释器所分配的内存，例如由扩展模块所分配的内存目前是不会被释放的。

调试构建¶

Python 可以附带某些宏来编译以启用对解释器和扩展模块的额外检查。这些检查会给运行时增加大量额外开销因此它们默认未被启用。

A full list of the various types of debugging builds is in the file Misc/SpecialBuilds.txt in the Python source distribution. Builds are available that support tracing of reference counts, debugging the memory allocator, or low-level profiling of the main interpreter loop. Only the most frequently-used builds will be described in the remainder of this section.

Compiling the interpreter with the Py_DEBUG macro defined produces what is generally meant by "a debug build" of Python. Py_DEBUG is enabled in the Unix build by adding --with-pydebug to the ./configure command. It is also implied by the presence of the not-Python-specific _DEBUG macro. When Py_DEBUG is enabled in the Unix build, compiler optimization is disabled.

除了前面描述的引用计数调试之外，还执行以下额外检查：

额外检查将添加到对象分配器。
额外的检查将添加到解析器和编译器中。
检查从宽类型向窄类型的向下强转是否损失了信息。
许多断言被添加到字典和集合实现中。另外，集合对象需要 test_c_api() 方法。
输入参数的完整性检查被添加到框架创建中。
使用已知的无效模式初始化整型的存储，以捕获对未初始化数字的引用。
添加底层跟踪和额外的异常检查到虚拟机的运行时中。
添加额外的检查到 arena 内存实现。
添加额外调试到线程模块。

这里可能没有提到的额外的检查。

Defining Py_TRACE_REFS enables reference tracing. When defined, a circular doubly linked list of active objects is maintained by adding two extra fields to every PyObject. Total allocations are tracked as well. Upon exit, all existing references are printed. (In interactive mode this happens after every statement run by the interpreter.) Implied by Py_DEBUG.

有关更多详细信息，请参阅Python源代码中的 Misc/SpecialBuilds.txt 。

概述¶

代码标准¶

包含文件¶

有用的宏¶

对象、类型和引用计数¶

引用计数¶

引用计数细节¶

类型¶

异常¶

嵌入Python¶

调试构建¶

目录

上一个主题

下一个主题

本页