Operating System Utilities

Operating System Utilities¶
-
PyObject *PyOS_FSPath(PyObject *path)¶
- Return value: New reference. Part of the Stable ABI since version 3.6.
Return the file system representation for path. If the object is a
str
orbytes
object, then a new strong reference is returned. If the object implements theos.PathLike
interface, then__fspath__()
is returned as long as it is astr
orbytes
object. OtherwiseTypeError
is raised andNULL
is returned.Added in version 3.6.
-
int Py_FdIsInteractive(FILE *fp, const char *filename)¶
Return true (nonzero) if the standard I/O file fp with name filename is deemed interactive. This is the case for files for which
isatty(fileno(fp))
is true. If thePyConfig.interactive
is non-zero, this function also returns true if the filename pointer isNULL
or if the name is equal to one of the strings'<stdin>'
or'???'
.This function must not be called before Python is initialized.
-
void PyOS_BeforeFork()¶
- Part of the Stable ABI on platforms with fork() since version 3.7.
Function to prepare some internal state before a process fork. This should be called before calling
fork()
or any similar function that clones the current process. Only available on systems wherefork()
is defined.Warning
The C
fork()
call should only be made from the “main” thread (of the “main” interpreter). The same is true forPyOS_BeforeFork()
.Added in version 3.7.
-
void PyOS_AfterFork_Parent()¶
- Part of the Stable ABI on platforms with fork() since version 3.7.
Function to update some internal state after a process fork. This should be called from the parent process after calling
fork()
or any similar function that clones the current process, regardless of whether process cloning was successful. Only available on systems wherefork()
is defined.Warning
The C
fork()
call should only be made from the “main” thread (of the “main” interpreter). The same is true forPyOS_AfterFork_Parent()
.Added in version 3.7.
-
void PyOS_AfterFork_Child()¶
- Part of the Stable ABI on platforms with fork() since version 3.7.
Function to update internal interpreter state after a process fork. This must be called from the child process after calling
fork()
, or any similar function that clones the current process, if there is any chance the process will call back into the Python interpreter. Only available on systems wherefork()
is defined.Warning
The C
fork()
call should only be made from the “main” thread (of the “main” interpreter). The same is true forPyOS_AfterFork_Child()
.Added in version 3.7.
See also
os.register_at_fork()
allows registering custom Python functions to be called byPyOS_BeforeFork()
,PyOS_AfterFork_Parent()
andPyOS_AfterFork_Child()
.
-
void PyOS_AfterFork()¶
- Part of the Stable ABI on platforms with fork().
Function to update some internal state after a process fork; this should be called in the new process if the Python interpreter will continue to be used. If a new executable is loaded into the new process, this function does not need to be called.
Deprecated since version 3.7: This function is superseded by
PyOS_AfterFork_Child()
.
-
int PyOS_CheckStack()¶
- Part of the Stable ABI on platforms with USE_STACKCHECK since version 3.7.
Return true when the interpreter runs out of stack space. This is a reliable check, but is only available when
USE_STACKCHECK
is defined (currently on certain versions of Windows using the Microsoft Visual C++ compiler).USE_STACKCHECK
will be defined automatically; you should never change the definition in your own code.
-
typedef void (*PyOS_sighandler_t)(int)¶
- Part of the Stable ABI.
-
PyOS_sighandler_t PyOS_getsig(int i)¶
- Part of the Stable ABI.
Return the current signal handler for signal i. This is a thin wrapper around either
sigaction()
orsignal()
. Do not call those functions directly!
-
PyOS_sighandler_t PyOS_setsig(int i, PyOS_sighandler_t h)¶
- Part of the Stable ABI.
Set the signal handler for signal i to be h; return the old signal handler. This is a thin wrapper around either
sigaction()
orsignal()
. Do not call those functions directly!
-
int PyOS_InterruptOccurred(void)¶
- Part of the Stable ABI.
Check if a
SIGINT
signal has been received.Returns
1
if aSIGINT
has occurred and clears the signal flag, or0
otherwise.In most cases, you should prefer
PyErr_CheckSignals()
over this function.PyErr_CheckSignals()
invokes the appropriate signal handlers for all pending signals, allowing Python code to handle the signal properly. This function only detectsSIGINT
and does not invoke any Python signal handlers.This function is async-signal-safe and this function cannot fail. The caller must hold an attached thread state.
-
wchar_t *Py_DecodeLocale(const char *arg, size_t *size)¶
- Part of the Stable ABI since version 3.7.
Warning
This function should not be called directly: use the
PyConfig
API with thePyConfig_SetBytesString()
function which ensures that Python is preinitialized.This function must not be called before Python is preinitialized and so that the LC_CTYPE locale is properly configured: see the
Py_PreInitialize()
function.Decode a byte string from the filesystem encoding and error handler. If the error handler is surrogateescape error handler, undecodable bytes are decoded as characters in range U+DC80..U+DCFF; and if a byte sequence can be decoded as a surrogate character, the bytes are escaped using the surrogateescape error handler instead of decoding them.
Return a pointer to a newly allocated wide character string, use
PyMem_RawFree()
to free the memory. If size is notNULL
, write the number of wide characters excluding the null character into*size
Return
NULL
on decoding error or memory allocation error. If size is notNULL
,*size
is set to(size_t)-1
on memory error or set to(size_t)-2
on decoding error.The filesystem encoding and error handler are selected by
PyConfig_Read()
: seefilesystem_encoding
andfilesystem_errors
members ofPyConfig
.Decoding errors should never happen, unless there is a bug in the C library.
Use the
Py_EncodeLocale()
function to encode the character string back to a byte string.See also
The
PyUnicode_DecodeFSDefaultAndSize()
andPyUnicode_DecodeLocaleAndSize()
functions.Added in version 3.5.
Changed in version 3.7: The function now uses the UTF-8 encoding in the Python UTF-8 Mode.
Changed in version 3.8: The function now uses the UTF-8 encoding on Windows if
PyPreConfig.legacy_windows_fs_encoding
is zero;
-
char *Py_EncodeLocale(const wchar_t *text, size_t *error_pos)¶
- Part of the Stable ABI since version 3.7.
Encode a wide character string to the filesystem encoding and error handler. If the error handler is surrogateescape error handler, surrogate characters in the range U+DC80..U+DCFF are converted to bytes 0x80..0xFF.
Return a pointer to a newly allocated byte string, use
PyMem_Free()
to free the memory. ReturnNULL
on encoding error or memory allocation error.If error_pos is not
NULL
,*error_pos
is set to(size_t)-1
on success, or set to the index of the invalid character on encoding error.The filesystem encoding and error handler are selected by
PyConfig_Read()
: seefilesystem_encoding
andfilesystem_errors
members ofPyConfig
.Use the
Py_DecodeLocale()
function to decode the bytes string back to a wide character string.Warning
This function must not be called before Python is preinitialized and so that the LC_CTYPE locale is properly configured: see the
Py_PreInitialize()
function.See also
The
PyUnicode_EncodeFSDefault()
andPyUnicode_EncodeLocale()
functions.Added in version 3.5.
Changed in version 3.7: The function now uses the UTF-8 encoding in the Python UTF-8 Mode.
Changed in version 3.8: The function now uses the UTF-8 encoding on Windows if
PyPreConfig.legacy_windows_fs_encoding
is zero.
-
FILE *Py_fopen(PyObject *path, const char *mode)¶
Similar to
fopen()
, but path is a Python object and an exception is set on error.path must be a
str
object, abytes
object, or a path-like object.On success, return the new file pointer. On error, set an exception and return
NULL
.The file must be closed by
Py_fclose()
rather than calling directlyfclose()
.The file descriptor is created non-inheritable (PEP 446).
The caller must have an attached thread state.
Added in version 3.14.
-
int Py_fclose(FILE *file)¶
Close a file that was opened by
Py_fopen()
.On success, return
0
. On error, returnEOF
anderrno
is set to indicate the error. In either case, any further access (including another call toPy_fclose()
) to the stream results in undefined behavior.Added in version 3.14.
System Functions¶
These are utility functions that make functionality from the sys
module
accessible to C code. They all work with the current interpreter thread’s
sys
module’s dict, which is contained in the internal thread state structure.
-
PyObject *PySys_GetObject(const char *name)¶
- Return value: Borrowed reference. Part of the Stable ABI.
Return the object name from the
sys
module orNULL
if it does not exist, without setting an exception.
-
int PySys_SetObject(const char *name, PyObject *v)¶
- Part of the Stable ABI.
Set name in the
sys
module to v unless v isNULL
, in which case name is deleted from the sys module. Returns0
on success,-1
on error.
-
void PySys_ResetWarnOptions()¶
- Part of the Stable ABI.
Reset
sys.warnoptions
to an empty list. This function may be called prior toPy_Initialize()
.Deprecated since version 3.13, will be removed in version 3.15: Clear
sys.warnoptions
andwarnings.filters
instead.
-
void PySys_WriteStdout(const char *format, ...)¶
- Part of the Stable ABI.
Write the output string described by format to
sys.stdout
. No exceptions are raised, even if truncation occurs (see below).format should limit the total size of the formatted output string to 1000 bytes or less – after 1000 bytes, the output string is truncated. In particular, this means that no unrestricted “%s” formats should occur; these should be limited using “%.<N>s” where <N> is a decimal number calculated so that <N> plus the maximum size of other formatted text does not exceed 1000 bytes. Also watch out for “%f”, which can print hundreds of digits for very large numbers.
If a problem occurs, or
sys.stdout
is unset, the formatted message is written to the real (C level) stdout.
-
void PySys_WriteStderr(const char *format, ...)¶
- Part of the Stable ABI.
As
PySys_WriteStdout()
, but write tosys.stderr
or stderr instead.
-
void PySys_FormatStdout(const char *format, ...)¶
- Part of the Stable ABI.
Function similar to PySys_WriteStdout() but format the message using
PyUnicode_FromFormatV()
and don’t truncate the message to an arbitrary length.Added in version 3.2.
-
void PySys_FormatStderr(const char *format, ...)¶
- Part of the Stable ABI.
As
PySys_FormatStdout()
, but write tosys.stderr
or stderr instead.Added in version 3.2.
-
PyObject *PySys_GetXOptions()¶
- Return value: Borrowed reference. Part of the Stable ABI since version 3.7.
Return the current dictionary of
-X
options, similarly tosys._xoptions
. On error,NULL
is returned and an exception is set.Added in version 3.2.
-
int PySys_Audit(const char *event, const char *format, ...)¶
- Part of the Stable ABI since version 3.13.
Raise an auditing event with any active hooks. Return zero for success and non-zero with an exception set on failure.
The event string argument must not be NULL.
If any hooks have been added, format and other arguments will be used to construct a tuple to pass. Apart from
N
, the same format characters as used inPy_BuildValue()
are available. If the built value is not a tuple, it will be added into a single-element tuple.The
N
format option must not be used. It consumes a reference, but since there is no way to know whether arguments to this function will be consumed, using it may cause reference leaks.Note that
#
format characters should always be treated asPy_ssize_t
, regardless of whetherPY_SSIZE_T_CLEAN
was defined.sys.audit()
performs the same function from Python code.See also
PySys_AuditTuple()
.Added in version 3.8.
Changed in version 3.8.2: Require
Py_ssize_t
for#
format characters. Previously, an unavoidable deprecation warning was raised.
-
int PySys_AuditTuple(const char *event, PyObject *args)¶
- Part of the Stable ABI since version 3.13.
Similar to
PySys_Audit()
, but pass arguments as a Python object. args must be atuple
. To pass no arguments, args can be NULL.Added in version 3.13.
-
int PySys_AddAuditHook(Py_AuditHookFunction hook, void *userData)¶
Append the callable hook to the list of active auditing hooks. Return zero on success and non-zero on failure. If the runtime has been initialized, also set an error on failure. Hooks added through this API are called for all interpreters created by the runtime.
The userData pointer is passed into the hook function. Since hook functions may be called from different runtimes, this pointer should not refer directly to Python state.
This function is safe to call before
Py_Initialize()
. When called after runtime initialization, existing audit hooks are notified and may silently abort the operation by raising an error subclassed fromException
(other errors will not be silenced).The hook function is always called with an attached thread state by the Python interpreter that raised the event.
See PEP 578 for a detailed description of auditing. Functions in the runtime and standard library that raise events are listed in the audit events table. Details are in each function’s documentation.
If the interpreter is initialized, this function raises an auditing event
sys.addaudithook
with no arguments. If any existing hooks raise an exception derived fromException
, the new hook will not be added and the exception is cleared. As a result, callers cannot assume that their hook has been added unless they control all existing hooks.-
typedef int (*Py_AuditHookFunction)(const char *event, PyObject *args, void *userData)¶
The type of the hook function. event is the C string event argument passed to
PySys_Audit()
orPySys_AuditTuple()
. args is guaranteed to be aPyTupleObject
. userData is the argument passed to PySys_AddAuditHook().
Added in version 3.8.
-
typedef int (*Py_AuditHookFunction)(const char *event, PyObject *args, void *userData)¶
Process Control¶
-
void Py_FatalError(const char *message)¶
- Part of the Stable ABI.
Print a fatal error message and kill the process. No cleanup is performed. This function should only be invoked when a condition is detected that would make it dangerous to continue using the Python interpreter; e.g., when the object administration appears to be corrupted. On Unix, the standard C library function
abort()
is called which will attempt to produce acore
file.The
Py_FatalError()
function is replaced with a macro which logs automatically the name of the current function, unless thePy_LIMITED_API
macro is defined.Changed in version 3.9: Log the function name automatically.
-
void Py_Exit(int status)¶
- Part of the Stable ABI.
Exit the current process. This calls
Py_FinalizeEx()
and then calls the standard C library functionexit(status)
. IfPy_FinalizeEx()
indicates an error, the exit status is set to 120.Changed in version 3.6: Errors from finalization no longer ignored.
-
int Py_AtExit(void (*func)())¶
- Part of the Stable ABI.
Register a cleanup function to be called by
Py_FinalizeEx()
. The cleanup function will be called with no arguments and should return no value. At most 32 cleanup functions can be registered. When the registration is successful,Py_AtExit()
returns0
; on failure, it returns-1
. The cleanup function registered last is called first. Each cleanup function will be called at most once. Since Python’s internal finalization will have completed before the cleanup function, no Python APIs should be called by func.See also
PyUnstable_AtExit()
for passing avoid *data
argument.


C API Stability

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 fromPython.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.
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.
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 ofPY_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.Rather than using the
PY_VERSION_HEX
macro directly, hardcode a minimum minor version (e.g.0x030A0000
for Python 3.10) for stability when compiling with future Python versions.You can also define
Py_LIMITED_API
to3
. This works the same as0x03020000
(Python 3.2, the version that introduced Limited API).
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.
On Windows, extensions that use the Stable ABI should be linked against
python3.dll
rather than a version-specific library such as
python39.dll
.
On some platforms, Python will look for and load shared library files named
with the abi3
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 lower
versions of Python.
All functions in the Stable ABI are present as functions in Python’s shared library, not solely as macros. This makes them usable from languages that don’t use the C preprocessor.
Limited API Scope and Performance¶
The goal for the Limited API is to allow everything that is possible with the full C API, but possibly with a performance penalty.
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.
Without Py_LIMITED_API
defined, some C API functions are inlined or
replaced by macros.
Defining Py_LIMITED_API
disables this inlining, allowing stability as
Python’s data structures are improved, but possibly reducing performance.
By leaving out the Py_LIMITED_API
definition, it is possible to compile
a Limited API extension with a version-specific ABI. This can improve
performance for that Python version, but will limit compatibility.
Compiling with Py_LIMITED_API
will then yield an extension that can be
distributed where a version-specific one is not available – for example,
for prereleases of an upcoming Python version.
Limited API Caveats¶
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.
One issue that Py_LIMITED_API
does 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.
Another issue is that some struct fields are currently not hidden when
Py_LIMITED_API
is defined, even though they’re part of the Limited API.
For these reasons, we recommend testing an extension with all minor Python versions it supports, and preferably to build with the lowest such version.
We also recommend reviewing documentation of all used API to check
if it is explicitly part of the Limited API. Even with Py_LIMITED_API
defined, a few private declarations are exposed for technical reasons (or
even unintentionally, as bugs).
Also note that the Limited API is not necessarily stable: compiling with
Py_LIMITED_API
with Python 3.8 means that the extension will
run with Python 3.12, but it will not necessarily compile 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 of the Stable ABI, 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 ABI.
This is the case with Windows and macOS releases from python.org
and many
third-party distributors.
Contents of Limited API¶
Currently, the Limited API includes the following items:
PyErr_Display()
PyModuleDef_Base
PyModuleDef_Type
PyUnicode_AsDecodedObject()
PyUnicode_AsDecodedUnicode()
PyUnicode_AsEncodedObject()
PyUnicode_AsEncodedUnicode()
PyVarObject.ob_base
PyWeakReference
Py_FileSystemDefaultEncodeErrors
Py_FileSystemDefaultEncoding
Py_HasFileSystemDefaultEncoding
Py_UTF8Mode
Py_intptr_t
Py_uintptr_t
ssizessizeargfunc
ssizessizeobjargproc
symtable