C API and ABI Stability

Unless documented otherwise, Python’s C API is covered by the BackwardsCompatibility 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 periodor to fix serious issues.

CPython’s Application Binary Interface (ABI) is forward- andbackwards-compatible across a minor release (if these are compiled the sameway; seePlatform Considerations 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 withouta deprecation period. It is marked by thePyUnstable prefix in names.

  • Limited API, is compatible across several minor releases.WhenPy_LIMITED_API is defined, only this subset is exposedfromPython.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 toCPython developersto discuss adding public API for your use case.

Unstable C API

Any API named with thePyUnstable prefix exposes CPython implementationdetails, and may change in every minor release (e.g. from 3.9 to 3.10) withoutany 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 followCPython development and spend extra effort adjusting to changes.

Stable Application Binary Interface

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

Limited C API

Python 3.2 introduced theLimited API, a subset of Python’s C API.Extensions that only use the Limited API can becompiled once and be loaded on multiple versions of Python.Contents of the Limited API arelisted below.

Py_LIMITED_API

Define this macro before includingPython.h to opt in to only usethe Limited API, and to select the Limited API version.

DefinePy_LIMITED_API to the value ofPY_VERSION_HEXcorresponding to the lowest Python version your extension supports.The extension will be ABI-compatible with all Python 3 releasesfrom the specified one onward, and can use Limited API introduced up to thatversion.

Rather than using thePY_VERSION_HEX macro directly, hardcode a minimumminor version (e.g.0x030A0000 for Python 3.10) for stability whencompiling with future Python versions.

You can also definePy_LIMITED_API to3. This works the same as0x03020000 (Python 3.2, the version that introduced Limited API).

Stable ABI

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

Note

The Stable ABI prevents ABI issues, like linker errors due to missingsymbols or data corruption due to changes in structure layouts or functionsignatures.However, other changes in Python can change thebehavior of extensions.See Python’s Backwards Compatibility Policy (PEP 387) for details.

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

On Windows, extensions that use the Stable ABI should be linked againstpython3.dll rather than a version-specific library such aspython39.dll.

On some platforms, Python will look for and load shared library files namedwith theabi3 tag (e.g.mymodule.abi3.so).It does not check if such extensions conform to a Stable ABI.The user (or their packaging tools) need to ensure that, for example,extensions built with the 3.10+ Limited API are not installed for lowerversions of Python.

All functions in the Stable ABI are present as functions in Python’s sharedlibrary, not solely as macros. This makes them usable from languages that don’tuse the C preprocessor.

Limited API Scope and Performance

The goal for the Limited API is to allow everything that is possible with thefull C API, but possibly with a performance penalty.

For example, whilePyList_GetItem() is available, its “unsafe” macrovariantPyList_GET_ITEM() is not.The macro can be faster because it can rely on version-specific implementationdetails of the list object.

WithoutPy_LIMITED_API defined, some C API functions are inlined orreplaced by macros.DefiningPy_LIMITED_API disables this inlining, allowing stability asPython’s data structures are improved, but possibly reducing performance.

By leaving out thePy_LIMITED_API definition, it is possible to compilea Limited API extension with a version-specific ABI. This can improveperformance for that Python version, but will limit compatibility.Compiling withPy_LIMITED_API will then yield an extension that can bedistributed where a version-specific one is not available – for example,for prereleases of an upcoming Python version.

Limited API Caveats

Note that compiling withPy_LIMITED_API isnot a complete guarantee thatcode conforms to theLimited API or theStable ABI.Py_LIMITED_API only covers definitions, but an API alsoincludes other issues, such as expected semantics.

One issue thatPy_LIMITED_API does not guard against is calling a functionwith arguments that are invalid in a lower Python version.For example, consider a function that starts acceptingNULL for anargument. In Python 3.9,NULL now selects a default behavior, but inPython 3.8, the argument will be used directly, causing aNULL dereferenceand crash. A similar argument works for fields of structs.

Another issue is that some struct fields are currently not hidden whenPy_LIMITED_API is defined, even though they’re part of the Limited API.

For these reasons, we recommend testing an extension withall minor Pythonversions it supports, and preferably to build with thelowest such version.

We also recommend reviewing documentation of all used API to checkif it is explicitly part of the Limited API. Even withPy_LIMITED_APIdefined, a few private declarations are exposed for technical reasons (oreven unintentionally, as bugs).

Also note that the Limited API is not necessarily stable: compiling withPy_LIMITED_API with Python 3.8 means that the extension willrun with Python 3.12, but it will not necessarilycompile with Python 3.12.In particular, parts of the Limited API may be deprecated and removed,provided that the Stable ABI stays stable.

Platform Considerations

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

It is the responsibility of each particular distributor of Pythonto ensure that all Python versions on a particular platform are builtin a way that does not break the Stable ABI.This is the case with Windows and macOS releases frompython.org and manythird-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 beinginstalled for the wrong interpreter.It also does not takeplatform incompatibilitiesinto account.It can only be done after an extension is successfully loaded.

Despite these limitations, it is recommended that extension modules use thismechanism, so that detectable incompatibilities raise exceptions rather thancrash.

Most modules can use this check via thePy_mod_abislot and thePyABIInfo_VAR macro, for example like this:

PyABIInfo_VAR(abi_info);staticPyModuleDef_Slotmymodule_slots[]={{Py_mod_abi,&abi_info},...};

The full API is described below for advanced use cases.

intPyABIInfo_Check(PyABIInfo*info,constchar*module_name)
Part of theStable ABI since version 3.15.

Verify that the giveninfo is compatible with the currently runninginterpreter.

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

If the ABI is incompatible, the raised exception will beImportError.

Themodule_name argument can beNULL, or point to a NUL-terminatedUTF-8-encoded string used for error messages.

Note that ifinfo describes the ABI that the current code uses (as definedbyPyABIInfo_VAR, for example), using any other Python C APImay lead to crashes.In particular, it is not safe to examine the raised exception.

Added in version 3.15.

PyABIInfo_VAR(NAME)
Part of theStable ABI since version 3.15.

Define a staticPyABIInfo variable with the givenNAME thatdescribes the ABI that the current code will use.This macro expands to:

staticPyABIInfoNAME={1,0,PyABIInfo_DEFAULT_FLAGS,PY_VERSION_HEX,PyABIInfo_DEFAULT_ABI_VERSION}

Added in version 3.15.

typePyABIInfo
Part of theStable ABI (including all members) since version 3.15.
uint8_tabiinfo_major_version

The major version ofPyABIInfo. Can be set to:

  • 0 to skip all checking, or

  • 1 to specify this version ofPyABIInfo.

uint8_tabiinfo_minor_version

The minor version ofPyABIInfo.Must be set to0; larger values are reserved for backwards-compatiblefuture versions ofPyABIInfo.

uint16_tflags

This field is usually set to the following macro:

PyABIInfo_DEFAULT_FLAGS
Part of theStable ABI since version 3.15.

Default flags, based on current values of macros such asPy_LIMITED_API andPy_GIL_DISABLED.

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

ABI variant – one of:

PyABIInfo_STABLE
Part of theStable ABI since version 3.15.

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
Part of theStable ABI since version 3.15.

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

PyABIInfo_GIL
Part of theStable ABI since version 3.15.

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

uint32_tbuild_version

The version of the Python headers used to build the code, in the formatused byPY_VERSION_HEX.

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

uint32_tabi_version

The ABI version.

For the Stable ABI, this field should be the value ofPy_LIMITED_API(except ifPy_LIMITED_API is3; usePy_PACK_VERSION(3,2) in that case).

Otherwise, it should be set toPY_VERSION_HEX.

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

PyABIInfo_DEFAULT_ABI_VERSION
Part of theStable ABI since version 3.15.

The value that should be used for this field, based on currentvalues of macros such asPy_LIMITED_API,PY_VERSION_HEX andPy_GIL_DISABLED.

Added in version 3.15.

Contents of Limited API

Currently, theLimited API includes the following items: