The Python/C API, Release 3.13.

(continued from previous page)

except KeyError:
item = 0
dict[key] = item + 1

Here is the corresponding C code, in all its glory:

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 */

}

This example represents an endorsed use of the goto statement in C! It illustrates the use of
PyErr_ExceptionMatches() and PyErr_Clear() to handle specific exceptions, and the use of Py_XDECREF()
to dispose of owned references that may be NULL (note the 'X' in the name; Py_DECREF() would crash when
confronted with a NULL reference). It is important that the variables used to hold owned references are initialized to
NULL for this to work; likewise, the proposed return value is initialized to -1 (failure) and only set to success after
the final call made is successful.

1.5. Exceptions 11
The Python/C API, Release 3.13.7

1.6 Embedding Python

The one important task that only embedders (as opposed to extension writers) of the Python interpreter have to worry
about is the initialization, and possibly the finalization, of the Python interpreter. Most functionality of the interpreter
can only be used after the interpreter has been initialized.
The basic initialization function is Py_Initialize(). This initializes the table of loaded modules, and creates the
fundamental modules builtins, __main__, and sys. It also initializes the module search path (sys.path).
Py_Initialize() does not set the “script argument list” (sys.argv). If this variable is needed by Python code that
will be executed later, setting PyConfig.argv and PyConfig.parse_argv must be set: see Python Initialization
Configuration.
On most systems (in particular, on Unix and Windows, although the details are slightly different),
Py_Initialize() calculates the module search path based upon its best guess for the location of the standard
Python interpreter executable, assuming that the Python library is found in a fixed location relative to the Python
interpreter executable. In particular, it looks for a directory named lib/pythonX.Y relative to the parent directory
where the executable named python is found on the shell command search path (the environment variable PATH).
For instance, if the Python executable is found in /usr/local/bin/python, it will assume that the libraries are in
/usr/local/lib/pythonX.Y . (In fact, this particular path is also the “fallback” location, used when no executable
file named python is found along PATH.) The user can override this behavior by setting the environment variable
PYTHONHOME, or insert additional directories in front of the standard path by setting PYTHONPATH.

The embedding application can steer the search by setting PyConfig.program_name before calling
Py_InitializeFromConfig(). Note that PYTHONHOME still overrides this and PYTHONPATH is still inserted
in front of the standard path. An application that requires total control has to provide its own implementation of
Py_GetPath(), Py_GetPrefix(), Py_GetExecPrefix(), and Py_GetProgramFullPath() (all defined in
Modules/getpath.c).

Sometimes, it is desirable to “uninitialize” Python. For instance, the application may want to start over (make another
call to Py_Initialize()) or the application is simply done with its use of Python and wants to free memory allo-
cated by Python. This can be accomplished by calling Py_FinalizeEx(). The function Py_IsInitialized()
returns true if Python is currently in the initialized state. More information about these functions is given in a later
chapter. Notice that Py_FinalizeEx() does not free all memory allocated by the Python interpreter, e.g. memory
allocated by extension modules currently cannot be released.

1.7 Debugging Builds

Python can be built with several macros to enable extra checks of the interpreter and extension modules. These
checks tend to add a large amount of overhead to the runtime so they are not enabled by default.
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.
Py_DEBUG

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.
In addition to the reference count debugging described below, extra checks are performed, see Python Debug Build.
Defining Py_TRACE_REFS enables reference tracing (see the configure --with-trace-refs option). 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.)
Please refer to Misc/SpecialBuilds.txt in the Python source distribution for more detailed information.

12 Chapter 1. Introduction
 The Python/C API, Release 3.13.7

1.8 Recommended third party tools

The following third party tools offer both simpler and more sophisticated approaches to creating C, C++ and Rust
extensions for Python:
• Cython
• cffi
• HPy
• nanobind (C++)
• Numba
• pybind11 (C++)
• PyO3 (Rust)
• SWIG
Using tools such as these can help avoid writing code that is tightly bound to a particular version of CPython, avoid
reference counting errors, and focus more on your own code than on using the CPython API. In general, new ver-
sions of Python can be supported by updating the tool, and your code will often use newer and more efficient APIs
automatically. Some tools also support compiling for other implementations of Python from a single set of sources.
These projects are not supported by the same people who maintain Python, and issues need to be raised with the
projects directly. Remember to check that the project is still maintained and supported, as the list above may become
outdated.

µ See also

Python Packaging User Guide: Binary Extensions

The Python Packaging User Guide not only covers several available tools that simplify the creation of binary
extensions, but also discusses the various reasons why creating an extension module may be desirable in
the first place.

1.8. Recommended third party tools 13

The Python/C API, Release 3.13.7

14 Chapter 1. Introduction
 CHAPTER

TWO

C API 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 Platform 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 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.

2.1 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.

2.2 Stable Application Binary Interface

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.

2.2.1 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
Define this macro before including Python.h to opt in to only use the Limited API, and to select the Limited
API 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.

15