C API and ABI Stability

除非另有文档说明，Python 的 C API 将遵循 PEP 387 所描述的向下兼容策略。 对它的大部分改变都是源代码级兼容的（通常只会增加新的 API）。改变现有 API 或移除 API 只会在弃用期结束之后或需修复严重问题时才会发生。

CPython 的应用程序二进制接口（ABI）可以跨微版本向上和向下兼容（在以相同方式编译的情况下，参见下文 平台的考虑 一节）。因此，针对 Python 3.10.0 编译的代码将适用于 3.10.8，反之亦然，但对于 3.9.x 和 3.11.x 则需要单独编译。

存在具有不同稳定性预期的两个 C API 层次：

  • 不稳定 API，可能在次要版本中发生改变而没有弃用期。它的名称会以 PyUnstable 前缀来标记。

  • 受限 API，将会在多个次要版本间保持兼容。当定义了 Py_LIMITED_API 时，将只有这个子集会从 Python.h 对外公开。

这些将在下文中更详细地讨论。

带有一个下划线前缀的名称，如 _Py_InternalState，是可能不经通知就改变甚至是在补丁发布版中改变的私有 API。 如果你需要使用这样的 API，请考虑联系 CPython 开发团队 来讨论为你的应用场景添加公有 API。

不稳定 C API

任何名称带有 PyUnstable 前缀的 API 都将对外公开 CPython 的实现细节，并可能不加弃用警告即在次要版本中发生改变（例如从 3.9 到 3.10）。但是，它不会在问题修正发布版中改变（例如从 3.10.0 到 3.10.1）。

它通常是针对专门的，低层级的工具如调试器等。

使用此 API 的项目需要跟随 CPython 开发进程并花费额外的努力来适应改变。

Stable Application Binary Interfaces

Python's Stable ABI allows extensions to be compatible with multiple versions of Python, without recompilation.

备注

For simplicity, this document talks about extensions, but Stable ABI works the same way for all uses of the API – for example, embedding Python.

There are two Stable ABIs:

  • abi3, introduced in Python 3.2, is compatible with non-free-threaded builds of CPython.

  • abi3t, introduced in Python 3.15, is compatible with free-threaded builds of CPython. It has stricter API limitations than abi3.

    Added in version 3.15.0a8 (unreleased): abi3t was added in PEP 803

It is possible for an extension to be compiled for both abi3 and abi3t at the same time; the result will be compatible with both free-threaded and non-free-threaded builds of Python. Currently, this has no downsides compared to compiling for abi3t only.

Each Stable ABI is versioned using the first two numbers of the Python version. For example, Stable ABI 3.14 corresponds to Python 3.14. An extension compiled for Stable ABI 3.x is ABI-compatible with Python 3.x and above.

Extensions that target a stable ABI must only use a limited subset of the C API. This subset is known as the Limited API; its contents are listed below.

On Windows, extensions that use a Stable ABI should be linked against python3.dll rather than a version-specific library such as python39.dll. This library only exposes the relevant symbols.

On some platforms, Python will look for and load shared library files named with the abi3 or abi3t tag (for example, mymodule.abi3.so). Free-threaded interpreters only recognize the abi3t tag, while non-free-threaded ones will prefer abi3 but fall back to abi3t. Thus, extensions compatible with both ABIs should use the abi3t tag.

Python does not necessarily check that extensions it loads have compatible ABI. Extension authors are encouraged to add a check using the Py_mod_abi slot or the PyABIInfo_Check() function, but the user (or their packaging tool) is ultimately responsible for ensuring that, for example, extensions built for Stable ABI 3.10 are not installed for lower versions of Python.

All functions in Stable ABI are present as functions in Python's shared library, not solely as macros. This makes them usable are usable from languages that don't use the C preprocessor, including Python's ctypes.

Compiling for Stable ABI

备注

Build tools (such as, for example, meson-python, scikit-build-core, or Setuptools) often have a mechanism for setting macros and synchronizing them with extension filenames and other metadata. Prefer using such a mechanism, if it exists, over defining the macros manually.

The rest of this section is mainly relevant for tool authors, and for people who compile extensions manually.

参见

list of recommended tools in the Python Packaging User Guide

To compile for a Stable ABI, define one or both of the following macros to the lowest Python version your extension should support, in Py_PACK_VERSION format. Typically, you should choose a specific value rather than the version of the Python headers you are compiling against.

The macros must be defined before including Python.h. Since Py_PACK_VERSION is not available at this point, you will need to use the numeric value directly. For reference, the values for a few recent Python versions are:

0x30a0000  /* Py_PACK_VERSION(3.10) */
0x30b0000  /* Py_PACK_VERSION(3.11) */
0x30c0000  /* Py_PACK_VERSION(3.12) */
0x30d0000  /* Py_PACK_VERSION(3.13) */
0x30e0000  /* Py_PACK_VERSION(3.14) */
0x30f0000  /* Py_PACK_VERSION(3.15) */

When one of the macros is defined, Python.h will only expose API that is compatible with the given Stable ABI -- that is, the Limited API plus some definitions that need to be visible to the compiler but should not be used directly. When both are defined, Python.h will only expose API compatible with both Stable ABIs.

Py_LIMITED_API

Target abi3, that is, non-free-threaded builds of CPython. See above for common information.

Py_TARGET_ABI3T

Target abi3t, that is, free-threaded builds of CPython. See above for common information.

Added in version 3.15.0a8 (unreleased).

Both macros specify a target ABI; the different naming style is due to backwards compatibility.

Historical note

You can also define Py_LIMITED_API as 3. This works the same as 0x03020000 (Python 3.2, the version that introduced Stable ABI).

When both are defined, Python.h may, or may not, redefine Py_LIMITED_API to match Py_TARGET_ABI3T.

On a free-threaded build -- that is, when Py_GIL_DISABLED is defined -- Py_TARGET_ABI3T defaults to the value of Py_LIMITED_API. This means that there are two ways to build for both abi3 and abi3t:

  • define both Py_LIMITED_API and Py_TARGET_ABI3T, or

  • define only Py_LIMITED_API and:

    • on Windows, define Py_GIL_DISABLED;

    • on other systems, use the headers of free-threaded build of Python.

Stable ABI Scope and Performance

The goal for Stable ABI is to allow everything that is possible with the full C API, but possibly with a performance penalty. Generally, compatibility with Stable ABI will require some changes to an extension's source code.

For example, while PyList_GetItem() is available, its "unsafe" macro variant PyList_GET_ITEM() is not. The macro can be faster because it can rely on version-specific implementation details of the list object.

For another example, when not compiling for Stable ABI, some C API functions are inlined or replaced by macros. Compiling for Stable ABI disables this inlining, allowing stability as Python's data structures are improved, but possibly reducing performance.

By leaving out the Py_LIMITED_API or Py_TARGET_ABI3T definition, it is possible to compile Stable-ABI-compatible source for a version-specific ABI. A potentially faster version-specific extension can then be distributed alongside a version compiled for Stable ABI -- a slower but more compatible fallback.

Stable ABI Caveats

Note that compiling for Stable ABI is not a complete guarantee that code will be compatible with the expected Python versions. Stable ABI prevents ABI issues, like linker errors due to missing symbols or data corruption due to changes in structure layouts or function signatures. However, other changes in Python can change the behavior of extensions.

One issue that the Py_TARGET_ABI3T and Py_LIMITED_API macros do not guard against is calling a function with arguments that are invalid in a lower Python version. For example, consider a function that starts accepting NULL for an argument. In Python 3.9, NULL now selects a default behavior, but in Python 3.8, the argument will be used directly, causing a NULL dereference and crash. A similar argument works for fields of structs.

For these reasons, we recommend testing an extension with all minor Python versions it supports.

我们还建议查看所使用 API 的全部文档以检查其是否显式指明为受限 API 的一部分。即使定义了 Py_LIMITED_API，少数私有声明还是会出于技术原因（或者甚至是作为程序缺陷在无意中）被暴露出来。

Also note that while compiling with Py_LIMITED_API 3.8 means that the extension should load on Python 3.12, and compile with Python 3.12, the same source will not necessarily compile with Py_LIMITED_API set to 3.12. In general, parts of the Limited API may be deprecated and removed, provided that Stable ABI stays stable.

平台的考虑

ABI stability depends not only on Python, but also on the compiler used, lower-level libraries and compiler options. For the purposes of the Stable ABIs, these details define a “platform”. They usually depend on the OS type and processor architecture

It is the responsibility of each particular distributor of Python to ensure that all Python versions on a particular platform are built in a way that does not break the Stable ABIs, or the version-specific ABIs. This is the case with Windows and macOS releases from python.org and many third-party distributors.

ABI Checking

Added in version 3.15.

Python includes a rudimentary check for ABI compatibility.

This check is not comprehensive. It only guards against common cases of incompatible modules being installed for the wrong interpreter. It also does not take platform incompatibilities into account. It can only be done after an extension is successfully loaded.

Despite these limitations, it is recommended that extension modules use this mechanism, so that detectable incompatibilities raise exceptions rather than crash.

Most modules can use this check via the Py_mod_abi slot and the PyABIInfo_VAR macro, for example like this:

PyABIInfo_VAR(abi_info);

static PyModuleDef_Slot mymodule_slots[] = {
   {Py_mod_abi, &abi_info},
   ...
};

The full API is described below for advanced use cases.

int PyABIInfo_Check(PyABIInfo *info, const char *module_name)
属于 稳定 ABI 自 3.15 版起.

Verify that the given info is compatible with the currently running interpreter.

Return 0 on success. On failure, raise an exception and return -1.

If the ABI is incompatible, the raised exception will be ImportError.

The module_name argument can be NULL, or point to a NUL-terminated UTF-8-encoded string used for error messages.

Note that if info describes the ABI that the current code uses (as defined by PyABIInfo_VAR, for example), using any other Python C API may lead to crashes. In particular, it is not safe to examine the raised exception.

Added in version 3.15.

PyABIInfo_VAR(NAME)
属于 稳定 ABI 自 3.15 版起.

Define a static PyABIInfo variable with the given NAME that describes the ABI that the current code will use. This macro expands to:

static PyABIInfo NAME = {
    1, 0,
    PyABIInfo_DEFAULT_FLAGS,
    PY_VERSION_HEX,
    PyABIInfo_DEFAULT_ABI_VERSION
}

Added in version 3.15.

type PyABIInfo
属于 稳定 ABI （包括所有成员） 自 3.15 版起.
uint8_t abiinfo_major_version

The major version of PyABIInfo. Can be set to:

  • 0 to skip all checking, or

  • 1 to specify this version of PyABIInfo.

uint8_t abiinfo_minor_version

The minor version of PyABIInfo. Must be set to 0; larger values are reserved for backwards-compatible future versions of PyABIInfo.

uint16_t flags

This field is usually set to the following macro:

PyABIInfo_DEFAULT_FLAGS
属于 稳定 ABI 自 3.15 版起.

Default flags, based on current values of macros such as Py_LIMITED_API and Py_GIL_DISABLED.

Alternately, the field can be set to the following flags, combined by bitwise OR. Unused bits must be set to zero.

ABI variant -- one of:

PyABIInfo_STABLE
属于 稳定 ABI 自 3.15 版起.

Specifies that Stable ABI is used.

PyABIInfo_INTERNAL

Specifies ABI specific to a particular build of CPython. Internal use only.

Free-threading compatibility -- one of:

PyABIInfo_FREETHREADED
属于 稳定 ABI 自 3.15 版起.

Specifies ABI compatible with free-threaded builds of CPython. (That is, ones compiled with --disable-gil; with t in sys.abiflags)

PyABIInfo_GIL
属于 稳定 ABI 自 3.15 版起.

Specifies ABI compatible with non-free-threaded builds of CPython (ones compiled without --disable-gil).

PyABIInfo_FREETHREADING_AGNOSTIC
属于 稳定 ABI 自 3.15 版起.

Specifies ABI compatible with both free-threaded and non-free-threaded builds of CPython, that is, both abi3 and abi3t.

uint32_t build_version

The version of the Python headers used to build the code, in the format used by PY_VERSION_HEX.

This can be set to 0 to skip any checks related to this field. This option is meant mainly for projects that do not use the CPython headers directly, and do not emulate a specific version of them.

uint32_t abi_version

The ABI version.

For Stable ABI, this field should be the value of Py_LIMITED_API or Py_TARGET_ABI3T. If both are defined, use the smaller value. (If Py_LIMITED_API is 3; use Py_PACK_VERSION(3, 2) instead of 3.)

Otherwise, it should be set to PY_VERSION_HEX.

It can also be set to 0 to skip any checks related to this field.

PyABIInfo_DEFAULT_ABI_VERSION
属于 稳定 ABI 自 3.15 版起.

The value that should be used for this field, based on current values of macros such as Py_LIMITED_API, PY_VERSION_HEX and Py_GIL_DISABLED.

Added in version 3.15.

受限 API 的内容

This is the definitive list of Limited API for Python 3.15: