C API and ABI Stability

Unless documented otherwise, Python's C API is covered by the Backwards Compatibility Policy, PEP 387. Most changes to it are source-compatible (typically by only adding new API). Changing existing API or removing API is only done after a deprecation period or to fix serious issues.

CPython's Application Binary Interface (ABI) is forward- and backwards-compatible across a minor release (if these are compiled the same way; see Considérations relatives aux plateformes below). So, code compiled for Python 3.10.0 will work on 3.10.8 and vice versa, but will need to be compiled separately for 3.9.x and 3.11.x.

There are two tiers of C API with different stability expectations:

  • Unstable API, may change in minor versions without a deprecation period. It is marked by the PyUnstable prefix in names.

  • Limited API, is compatible across several minor releases. When Py_LIMITED_API is defined, only this subset is exposed from Python.h.

These are discussed in more detail below.

Names prefixed by an underscore, such as _Py_InternalState, are private API that can change without notice even in patch releases. If you need to use this API, consider reaching out to CPython developers to discuss adding public API for your use case.

Unstable C API

Any API named with the PyUnstable prefix exposes CPython implementation details, and may change in every minor release (e.g. from 3.9 to 3.10) without any deprecation warnings. However, it will not change in a bugfix release (e.g. from 3.10.0 to 3.10.1).

It is generally intended for specialized, low-level tools like debuggers.

Projects that use this API are expected to follow CPython development and spend extra effort adjusting to changes.

ABI stable

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

Limited C API

Python 3.2 introduced the Limited API, a subset of Python's C API. Extensions that only use the Limited API can be compiled once and be loaded on multiple versions of Python. Contents of the Limited API are listed below.

Py_LIMITED_API

Définissez cette macro avant d’inclure Python.h pour n’inclure que l’API restreinte et indiquer sa version.

Define Py_LIMITED_API to the value of PY_VERSION_HEX corresponding to the lowest Python version your extension supports. The extension will be ABI-compatible with all Python 3 releases from the specified one onward, and can use Limited API introduced up to that version.

Il est recommandé de renseigner une version mineure minimale (par exemple 0x030A0000 pour Python 3.10) plutôt que d’utiliser directement la macro PY_VERSION_HEX pour ne pas dépendre de la version de Python utilisée lors de la compilation.

Vous pouvez aussi définir Py_LIMITED_API à 3. Cette valeur est équivalente à 0x03020000 correspondant à Python 3.2, la première version à supporter l’API restreinte.

Stable ABI

To enable this, Python provides a Stable ABI: a set of symbols that will remain ABI-compatible across Python 3.x versions.

Note

The 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. See Python's Backwards Compatibility Policy (PEP 387) for details.

The Stable ABI contains symbols exposed in the Limited API, but also other ones – for example, functions necessary to support older versions of the Limited API.

Sur Windows les extensions qui utilisent l’ABI stable doivent être liées avec python3.dll et non pas avec une bibliothèque spécifique à une version comme python39.dll.

Sur certaines plateformes Python essaiera de charger une bibliothèque partagée dont le nom contient abi3 (par exemple mymodule.abi3.so). Il ne vérifie pas si ces extensions respectent l’ABI stable. L’utilisateur (ou ses outils d’administration) doit s’assurer que les extensions compilées avec une version donnée de l’API restreinte, par exemple 3.10+, ne sont pas utilisées avec des versions plus anciennes de Python.

Toutes les fonctions de l’ABI stable sont présentes dans la bibliothèque dynamique de Python en tant que fonction, et pas uniquement comme macro. Elles peuvent donc être utilisées avec des langages qui n’utilisent pas le pré-processeur C.

Porté de l’API restreinte et performance

L’objectif de l’API restreinte est de permettre l’ensemble des opérations possibles avec l’API C étendue, mais peut avoir un impact sur les performances.

Par exemple la fonction PyList_GetItem() est disponible, mais la macro « dangereuse » PyList_GET_ITEM() ne l’est pas. Cette macro peut être plus rapide car elle dépend de détails d’implémentation spécifique à l’objet list.

Si Py_LIMITED_API n’est pas défini certaines fonctions de l’API C seront remplacées par des macros ou une version en-ligne. Définir Py_LIMITED_API désactive cette optimisation, permettant de se garantir contre les évolutions des structures de données utilisées par Python, et peut réduire les performances.

En omettant la définition de Py_LIMITED_API il est possible de compiler une extension utilisant l’API restreinte avec une version spécifique de l’ABI. Les performances seront meilleures pour cette version de Python, mais la compatibilité sera réduite. Compiler en définissant Py_LIMITED_API produira une extension qui peut être utilisée quand une variante spécifique à une version n’est pas disponible — par exemple pour une version alpha de Python.

Inconvénients de l’API restreinte

Note that compiling with Py_LIMITED_API is not a complete guarantee that code conforms to the Limited API or the Stable ABI. Py_LIMITED_API only covers definitions, but an API also includes other issues, such as expected semantics.

Une des limitations est que Py_LIMITED_API ne protège pas contre l’appel d’une fonction avec des arguments qui sont invalides pour une version de Python plus ancienne. Par exemple considérons une fonction qui accepte NULL comme argument à partir de 3.9. NULL permet maintenant d’utiliser le comportement par défaut, mais Python 3.8 essayera d’accéder à l’objet pointé et dé-référencera NULL, causant un crash. Des problèmes similaires peuvent se produire avec les attributs des structures.

Un autre problème est que certains attributs ne sont pas encore cachés lorsque Py_LIMITED_API est défini, même s’ils ne font pas partie de l’API restreinte.

Pour ces raisons il est recommandé de tester une extension avec l’ensemble des versions mineures supportées de Python, et généralement de la compiler avec la plus ancienne de ces versions.

Il est aussi recommandé de vérifier la documentation de toutes les API utilisées pour vérifier qu’elles fassent bien partie de l’API restreinte. Même lorsque Py_LIMITED_API est défini quelques fonctions privées peuvent être exposées aux utilisateurs pour des raisons techniques, ou par erreur.

Notez aussi que l’API restreinte n’est pas forcément stable : compiler avec Python 3.8 en définissant Py_LIMITED_API garanti que l’extension fonctionnera avec Python 3.12, mais pas qu’elle pourra être compilée avec Python 3.12. En particulier certaines parties de l’API restreinte peuvent être dépréciées et retirées tant que l’ABI stable n’est pas modifiée.

Considérations relatives aux plateformes

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 ABI, these details define a “platform”. They usually depend on the OS type and processor architecture

Les distributeurs de Python doivent s’assurer que toutes les versions de Python pour une plateforme donnée sont compilées de manière à ne pas rompre la compatibilité de l’ABI stable. C’est le cas des versions produites pour Windows et macOS de python.org et de la plupart des distributions tierces.

ABI Checking

Ajouté dans la version 3.15.0a0 (unreleased).

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)
Part of the Stable ABI Depuis la version 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.

Ajouté dans la version 3.15.0a0 (unreleased).

PyABIInfo_VAR(NAME)
Part of the Stable ABI Depuis la version 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
}

Ajouté dans la version 3.15.0a0 (unreleased).

type PyABIInfo
Part of the Stable ABI (including all members) Depuis la version 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 major 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

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

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

ABI variant -- one of:

PyABIInfo_STABLE

Specifies that the 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

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

PyABIInfo_GIL

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

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 the Stable ABI, this field should be the value of Py_LIMITED_API (except if Py_LIMITED_API is 3; use Py_PACK_VERSION(3, 2) in that case).

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

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.

Ajouté dans la version 3.15.0a0 (unreleased).

Contenu de l’API restreinte

Currently, the Limited API includes the following items: