概述

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_ABS(x)

返回 x 的绝对值。

3.3 新版功能.

Py_ALWAYS_INLINE

让编译器始终内联静态的内联函数。 编译器可以忽略它并决定不内联该函数。

它可被用来在禁用函数内联的调试模式下构建 Python 时内联严重影响性能的静态内联函数。 例如，MSC 在调试模式下构建时就禁用了函数内联。

随意使用 Py_ALWAYS_INLINE 标记内联函数可能导致极差的性能（例如由于增加了代码量）。 对于成本/收益分析来说计算机通常都比开发者更聪明。

如果 Python 是 在调试模式下构建 (即定义了 Py_DEBUG 宏)，则 Py_ALWAYS_INLINE 宏将不做任何事情。

它必须在函数返回类型之前指明。 用法:

static inline Py_ALWAYS_INLINE int random(void) { return 4; }

3.11 新版功能.

Py_CHARMASK(c)

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

Py_DEPRECATED(version)

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

示例:

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

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

Py_GETENV(s)

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

Py_MAX(x, y)

返回 x 和 y 当中的最大值。

3.3 新版功能.

Py_MEMBER_SIZE(type, member)

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

3.6 新版功能.

Py_MIN(x, y)

返回 x 和 y 当中的最小值。

3.3 新版功能.

Py_NO_INLINE

启用内联某个函数。 例如，它会减少 C 栈消耗：适用于大量内联代码的 LTO+PGO 编译版 (参见 bpo-33720)。

用法：

Py_NO_INLINE static int random(void) { return 4; }

3.11 新版功能.

Py_STRINGIFY(x)

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

3.4 新版功能.

Py_UNREACHABLE()

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

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

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

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

3.7 新版功能.

Py_UNUSED(arg)

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

3.4 新版功能.

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) 为真。

引用计数

The reference count is important because today's computers have a finite (and often severely limited) memory size; it counts how many different places there are that have a strong reference to an object. Such a place could be another object, or a global (or static) C variable, or a local variable in some C function. When the last strong reference to an object is released (i.e. its reference count becomes zero), the object is deallocated. If it contains references to other objects, those references are released. Those other objects may be deallocated in turn, if there are no more references to them, and so on. (There's an obvious problem with objects that reference each other here; for now, the solution is "don't do that.")

Reference counts are always manipulated explicitly. The normal way is to use the macro Py_INCREF() to take a new reference to an object (i.e. increment its reference count by one), and Py_DECREF() to release that reference (i.e. decrement the reference count by one). The Py_DECREF() macro is considerably more complex than the incref one, since it must check whether the reference count becomes zero and then cause the object's deallocator to be called. The deallocator is a function pointer contained in the object's type structure. The type-specific deallocator takes care of releasing references for other objects contained in the object if this is a compound object type, such as a list, as well as performing any additional finalization that's needed. There's no chance that the reference count can overflow; at least as many bits are used to hold the reference count as there are distinct memory locations in virtual memory (assuming sizeof(Py_ssize_t) >= sizeof(void*)). Thus, the reference count increment is a simple operation.

It is not necessary to hold a strong reference (i.e. increment the reference count) for every local variable that contains a pointer to an object. In theory, the object's reference count goes up by one when the variable is made to point to it and it goes down by one when the variable goes out of scope. However, these two cancel each other out, so at the end the reference count hasn't changed. The only real reason to use the reference count is to prevent the object from being deallocated as long as our variable is pointing to it. If we know that there is at least one other reference to the object that lives at least as long as our variable, there is no need to take a new strong reference (i.e. increment the reference count) temporarily. An important situation where this arises is in objects that are passed as arguments to C functions in an extension module that are called from Python; the call mechanism guarantees to hold a reference to every argument for the duration of the call.

However, a common pitfall is to extract an object from a list and hold on to it for a while without taking a new reference. Some other operation might conceivably remove the object from the list, releasing that reference, and possibly deallocating it. The real danger is that innocent-looking operations may invoke arbitrary Python code which could do this; there is a code path which allows control to flow back to the user from a Py_DECREF(), so almost any operation is potentially dangerous.

A safe approach is to always use the generic operations (functions whose name begins with PyObject_, PyNumber_, PySequence_ or PyMapping_). These operations always create a new strong reference (i.e. increment the reference count) of the object they return. This leaves the caller with the responsibility to call Py_DECREF() when they are done with the result; this soon becomes second nature.

引用计数细节

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 releasing 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");

It is much more common to use PyObject_SetItem() and friends with items whose references you are only borrowing, like arguments that were passed in to the function you are writing. In that case, their behaviour regarding references is much saner, since you don't have to take a new reference just so you can give that reference away ("have it be stolen"). For example, this function sets all items of a list (actually, any mutable sequence) to a given item:

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* 等。 有一些结构类型被用来燃烧液体于列出模块所导出的函数或者某个新对象类型的个的一个，还有一个结构类型被用来描述复数的值。 这些结构类型将与使用它们的函数放到一起讨论。

type Py_ssize_t

Part of the Stable ABI.

一个使得 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 代码需要此变量，则要设置 PyConfig.argv 并且还要设置 PyConfig.parse_argv: 参见 Python 初始化配置。

在大多数系统上（特别是 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 可以附带某些宏来编译以启用对解释器和扩展模块的额外检查。 这些检查会给运行时增加大量额外开销因此它们默认未被启用。

各种调试构建版的完整列表见 Python 源代码颁发包中的 Misc/SpecialBuilds.txt。 可用的构建版有支持追踪引用计数，调试内存分配器，或是对主解释器事件循环的低层级性能分析等等。 本节的剩余部分将只介绍最常用的几种构建版。

附带定义 Py_DEBUG 宏来编译解释器将产生通常所称的 Python 调试编译版。 Py_DEBUG 在 Unix 编译中启用是通过添加 --with-pydebug 到 ./configure 命令来实现的。 它也可通过提供非 Python 专属的 _DEBUG 宏来启用。 当 Py_DEBUG 在 Unix 编译中启用时，编译器优化将被禁用。

除了下文描述的引用计数调试，还会执行额外检查，请参阅 Python Debug Build。

定义 Py_TRACE_REFS 将启用引用追踪 (参见 configure --with-trace-refs 选项)。 当定义了此宏时，将通过在每个 PyObject 上添加两个额外字段来维护一个活动对象的循环双链列表。 总的分配量也会被追踪。 在退出时，所有现存的引用将被打印出来。 （在交互模式下这将在解释器运行每条语句之后发生）。

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