Features reference

PyO3 provides a number of Cargo features to customize functionality. This chapter of the guide provides detail on each of them.

By default, only the macros feature is enabled.

Features to select the target ABI

Each version of CPython exposes an ABI corresponding to the C API that is particular to that version. Extensions built for this “version-specific” ABI can only be imported by Python interpreters with the same major version, since the Python C API and ABI are subject to change in every major release. Python also supports a limited API and stable ABI. Extensions targeting the stable ABI defined by Python 3.X can be imported by any subsequent Python version newer than Python 3.X, but not older versions.

There are two “flavors” of stable ABI: abi3, supported on Python 3.2 and newer but not the free-threaded builds and abi3t, supported on Python 3.15 and newer for both the GIL-enabled and free-threaded builds of Python. PyO3 supports building extensions targeting both flavors of stable ABI.

When PyO3 finds a “host” python interpreter and no abi3 or abi3t feature is active, it will generate extensions targetting the version-specific ABI for the host Python version. For example, when pip or uv installs a Python package that includes Rust dependencies that depend on PyO3, the host interpreter is the interpreter running pip or the interpreter from the activated uv environment.

To build for the stable ABIs, you must activate an abi3 and/or an abi3t feature. You can simultaneously activate both features. This will produce an abi3 extension on the GIL-enabled and a version-specific extension on Python 3.14 and an abi3t extension on Python 3.15 and newer.

`abi3`

This feature is used when building Python extension modules to create wheels which are compatible with multiple Python versions but not the free-threaded build.

It restricts PyO3’s API to a subset of the full Python API which is guaranteed by PEP 384 to be forwards-compatible with future Python versions.

Since no particular “target” Python version is implied by this feature, it will generate an abi3 extension targeting the stable ABI defined by the “host” Python interpreter. As such, this feature requires a host Python interpreter is present and cannot be used for cross-compilation.

If you are using this feature to distribute extensions, you should ensure your minimum supported Python version is installed to do the build. However, see the description of the abi3-pyXY feature if you would like to generate extensions targeting an older Python version using a recent Python interpreter.

See the building and distribution section for further detail.

The `abi3-pyXY` features

(abi3-py38, abi3-py39, abi3-py310, abi3-py311, abi3-py312, abi3-py313 and abi3-py314)

These features are extensions of the abi3 feature to specify the exact minimum Python version which the multiple-version-wheel will support.

They can be used to target versions of the ABI defined by Python versions released before the “host” python interpreter. They can also be used without any host interpreter at all to cross-compile.

See the building and distribution section for further detail.

`abi3t`

This feature is used when building Python extension modules to create wheels which are compatible with Python 3.15 or newer, targeting both the free-threaded and GIL-enabled build with a single extension module.

It restricts PyO3’s API to a subset of the full Python API which is guaranteed by PEP 384 and PEP 803 to be forwards-compatible with future Python versions and be importable by the free-threaded and GIL-enabled interpreter.

If you are using this feature to distribute extensions, you should ensure your minimum supported Python version is installed to do the build. However, see the description of the abi3t-pyXY feature if you would like to generate extensions targeting an older Python version using a recent Python interpreter.

Activating an abi3t and targeting Python 3.14 and older is a no-op: the build will produce an extension but it will not be an abi3t extension, since abi3t is unsupported before Python 3.15.

See the building and distribution section for further detail.

The `abi3t-pyXY` features

(abi3t-py315)

These features are extensions of the abi3t feature to specify the exact minimum Python version which the multiple-version-wheel will support.

Activating an abi3t and targeting Python 3.14 and older is a no-op: the build will produce an extension but it will not be an abi3t extension, since abi3t is unsupported before Python 3.15.

See the building and distribution section for further detail.

Features for embedding Python in Rust

`auto-initialize`

This feature changes Python::attach to automatically initialize a Python interpreter (by calling Python::initialize) if needed.

If you do not enable this feature, you should call Python::initialize() before attempting to call any other Python APIs.

Advanced Features

`experimental-async`

This feature adds support for async fn in #[pyfunction] and #[pymethods].

The feature has some unfinished refinements and performance improvements. To help finish this off, see issue #1632 and its associated draft PRs.

`experimental-inspect`

This feature adds to the built binaries introspection data that can be then retrieved using the pyo3-introspection crate to generate type stubs.

Also, this feature adds the pyo3::inspect module, as well as IntoPy::type_output and FromPyObject::type_input APIs to produce Python type “annotations” for Rust types.

This is a first step towards adding first-class support for generating type annotations automatically in PyO3, however work is needed to finish this off. All feedback and offers of help welcome on issue #2454.

`py-clone`

This feature was introduced to ease migration. It was found that delayed reference counting (which PyO3 used historically) could not be made sound and hence Clone-ing an instance of Py<T> is impossible when not attached to Python interpreter (it will panic). To avoid migrations introducing new panics without warning, the Clone implementation itself is now gated behind this feature.

`pyo3_disable_reference_pool`

This is a performance-oriented conditional compilation flag, e.g. set via $RUSTFLAGS, which disabled the global reference pool and the associated overhead for the crossing the Python-Rust boundary. However, if enabled, Dropping an instance of Py<T> when not attached to the Python interpreter will abort the process.

`macros`

This feature enables a dependency on the pyo3-macros crate, which provides the procedural macros portion of PyO3’s API:

#[pymodule]
#[pyfunction]
#[pyclass]
#[pymethods]
#[derive(FromPyObject)]

It also provides the py_run! macro.

These macros require a number of dependencies which may not be needed by users who just need PyO3 for Python FFI. Disabling this feature enables faster builds for those users, as these dependencies will not be built if this feature is disabled.

Note

This feature is enabled by default. To disable it, set default-features = false for the pyo3 entry in your Cargo.toml.

`multiple-pymethods`

This feature enables each #[pyclass] to have more than one #[pymethods] block.

Most users should only need a single #[pymethods] per #[pyclass]. In addition, not all platforms (e.g. Wasm) are supported by inventory, which is used in the implementation of the feature. For this reason this feature is not enabled by default, meaning fewer dependencies and faster compilation for the majority of users.

See the #[pyclass] implementation details for more information.

`nightly`

The nightly feature needs the nightly Rust compiler. This allows PyO3 to use the auto_traits and negative_impls features to fix the Python::detach function.

Optional Dependencies

These features enable conversions between Python types and types from other Rust crates, enabling easy access to the rest of the Rust ecosystem.

`anyhow`

Adds a dependency on anyhow. Enables a conversion from anyhow’s Error type to PyErr, for easy error handling.

`arc_lock`

Enables Pyo3’s MutexExt trait for all Mutexes that extend on lock_api::Mutex or parking_lot::ReentrantMutex and are wrapped in an Arc type. Like Arc<parking_lot::Mutex>

`bigdecimal`

Adds a dependency on bigdecimal and enables conversions into its BigDecimal type.

`bytes`

Adds a dependency on bytes and enables conversions into its Bytes type.

`chrono`

Adds a dependency on chrono. Enables a conversion from chrono’s types to python:

`chrono-local`

Enables conversion from and to Local timezones. The current system timezone as determined by iana_time_zone::get_timezone() will be used for conversions.

chrono::DateTime<Local> will convert from either of:

datetime objects with tzinfo equivalent to the current system timezone.
“naive” datetime objects (those without a tzinfo), as it is a convention that naive datetime objects should be treated as using the system timezone.

When converting to Python, Local tzinfo is converted to a zoneinfo.ZoneInfo matching the current system timezone.

`chrono-tz`

Adds a dependency on chrono-tz. Enables conversion from and to Tz.

`either`

Adds a dependency on either. Enables a conversions into either’s Either type.

`eyre`

Adds a dependency on eyre. Enables a conversion from eyre’s Report type to PyErr, for easy error handling.

`hashbrown`

Adds a dependency on hashbrown and enables conversions into its HashMap and HashSet types.

`indexmap`

Adds a dependency on indexmap and enables conversions into its IndexMap type.

`jiff-02`

Adds a dependency on jiff@0.2. Enables a conversion from jiff’s types to python:

`lock_api`

Adds a dependency on lock_api and enables Pyo3’s MutexExt trait for all mutexes that extend on lock_api::Mutex and parking_lot::ReentrantMutex (like parking_lot or spin).

`num-bigint`

Adds a dependency on num-bigint and enables conversions into its BigInt and BigUint types.

`num-complex`

Adds a dependency on num-complex and enables conversions into its Complex type.

`num-rational`

Adds a dependency on num-rational and enables conversions into its Ratio type.

`ordered-float`

Adds a dependency on ordered-float and enables conversions between ordered-float’s types and Python:

NotNan -> PyFloat
OrderedFloat -> PyFloat

`parking-lot`

Adds a dependency on parking_lot and enables Pyo3’s OnceExt & MutexExt traits for parking_lot::Once parking_lot::Mutex and parking_lot::ReentrantMutex types.

`rust_decimal`

Adds a dependency on rust_decimal and enables conversions into its Decimal type.

`time`

Adds a dependency on time. Enables conversions between time’s types and Python:

`serde`

Enables (de)serialization of Py<T> objects via serde. This allows to use #[derive(Serialize, Deserialize) on structs that hold references to #[pyclass] instances

#[cfg(feature = "serde")]
#[allow(dead_code)]
mod serde_only {
use pyo3::prelude::*;
use serde::{Deserialize, Serialize};

#[pyclass]
#[derive(Serialize, Deserialize)]
struct Permission {
    name: String,
}

#[pyclass]
#[derive(Serialize, Deserialize)]
struct User {
    username: String,
    permissions: Vec<Py<Permission>>,
}
}

`smallvec`

Adds a dependency on smallvec and enables conversions into its SmallVec type.

`uuid`

Adds a dependency on uuid and enables conversions into its Uuid type.

Deprecated features for extension module authors

`extension-module`

Deprecated, users should remove this feature and upgrade to maturin >= 1.9.4 or setuptools-rust >= 1.12.

See the building and distribution section for further detail.

`generate-import-lib`

This feature is deprecated and has no effect. PyO3 now uses Rust’s raw-dylib linking feature to link against the Python DLL on Windows, eliminating the need for import library (.lib) files entirely. Cross-compiling for Windows targets works without any additional setup.

Keyboard shortcuts

PyO3 user guide