Upgrade guide#

This is a companion guide to the Changelog. While the changelog briefly lists all of the new features, improvements and bug fixes, this upgrade guide focuses only the subset which directly impacts your experience when upgrading to a new version. But it goes into more detail. This includes things like deprecated APIs and their replacements, build system changes, general code modernization and other useful information.

v3.0#

pybind11 v3.0 introduces major new features, but the vast majority of existing extensions are expected to build and run without modification. Minor adjustments may be needed in rare cases, and any such changes can be easily wrapped in preprocessor conditionals to maintain compatibility with the 2.x series.

However, due to new features and modernizations, extensions built with pybind11 v3.0 are not ABI-compatible with those built using v2.13. To ensure cross-extension-module compatibility, it is recommended to rebuild all pybind11-based extensions with v3.0.

CMake support now defaults to the modern FindPython module. If you haven’t updated yet, we provide some backward compatibility for PYTHON_* variables, but you should switch to using Python_* variables instead. Note that setting PYTHON_* variables no longer affects the build.

A major new feature in this release is the integration of py::smart_holder, which improves support for std::unique_ptr and std::shared_ptr, resolving several long-standing issues. See py::smart_holder for details. Closely related is the addition of py::trampoline_self_life_support, documented under Overriding virtual functions in Python.

This release includes a major modernization of cross-extension-module ABI compatibility handling. The new implementation reflects actual ABI compatibility much more accurately than in previous versions. The details are subtle and complex; see #4953 and #5439.

Also new in v3.0 is py::native_enum, a modern API for exposing C++ enumerations as native Python types — typically standard-library enum.Enum or related subclasses. This provides improved integration with Python’s enum system, compared to the older (now deprecated) py::enum_. See #5555 for details.

Functions exposed with pybind11 are now pickleable. This removes a long-standing obstacle when using pybind11-bound functions with Python features that rely on pickling, such as multiprocessing and caching tools. See #5580 for details.

Anything producing a deprecation warning in the 2.x series may be removed in a future minor release of 3.x. Most of these are still present in 3.0 in order to ease transition. The new Deprecated page details deprecations.

Migration Recommendations#

We recommend migrating to pybind11 v3.0 promptly, while keeping initial changes to a minimum. Most projects can upgrade simply by updating the pybind11 version, without altering existing binding code.

After a short stabilization period — enough to surface any subtle issues — you may incrementally adopt new features where appropriate:

  • Use py::smart_holder and py::trampoline_self_life_support as needed, or to improve code health. Note that py::classh is available as a shortcut — for example, py::classh<Pet> is shorthand for py::class_<Pet, py::smart_holder>. This is designed to enable easy experimentation with py::smart_holder without introducing distracting whitespace changes. In many cases, a global replacement of py::class_ with py::classh can be an effective first step. Build failures will quickly identify places where std::shared_ptr<...> holders need to be removed. Runtime failures (assuming good unit test coverage) will highlight base-and-derived class situations that require coordinated changes.

    Note that py::bind_vector and py::bind_map (in pybind11/stl_bind.h) have a holder_type template parameter that defaults to std::unique_ptr. If py::smart_holder functionality is desired or required, use e.g. py::bind_vector<VecType, py::smart_holder>.

  • Gradually migrate from py::enum_ to py::native_enum to improve integration with Python’s standard enum types.

There is no urgency to refactor existing, working bindings — adopt new features as the need arises or as part of ongoing maintenance efforts.

If you are using CMake, update to FindPython variables (mostly changing variables from PYTHON_* -> Python_*). You should see if you can use set(PYBIND11_FINDPYTHON ON), which has been supported for years and will avoid setting the compatibility mode variables (and will avoid a warning).

Potential stumbling blocks when migrating to v3.0#

The following issues are very unlikely to arise, and easy to work around:

  • In rare cases, a C++ enum may be bound to Python via a custom type caster. In such cases, a template specialization like this may be required:

    #if defined(PYBIND11_HAS_NATIVE_ENUM)
namespace pybind11::detail {
template <typename FancyEnum>
struct type_caster_enum_type_enabled<
    FancyEnum,
    enable_if_t<is_fancy_enum<FancyEnum>::value>> : std::false_type {};
}
#endif

    This specialization is needed only if the custom type caster is templated.

    The PYBIND11_HAS_NATIVE_ENUM guard is needed only if backward compatibility with pybind11v2 is required.

  • Similarly, template specializations like the following may be required if there are custom

    • pybind11::detail::copyable_holder_caster or

    • pybind11::detail::move_only_holder_caster

    implementations that are used for std::shared_ptr or std::unique_ptr conversions:

    #if defined(PYBIND11_HAS_INTERNALS_WITH_SMART_HOLDER_SUPPORT)
namespace pybind11::detail {
template <typename ExampleType>
struct copyable_holder_caster_shared_ptr_with_smart_holder_support_enabled<
    ExampleType,
    enable_if_t<is_example_type<ExampleType>::value>> : std::false_type {};
}
#endif

    #if defined(PYBIND11_HAS_INTERNALS_WITH_SMART_HOLDER_SUPPORT)
namespace pybind11::detail {
template <typename ExampleType>
struct move_only_holder_caster_unique_ptr_with_smart_holder_support_enabled<
    ExampleType,
    enable_if_t<is_example_type<ExampleType>::value>> : std::false_type {};
}
#endif

    The PYBIND11_HAS_INTERNALS_WITH_SMART_HOLDER_SUPPORT guard is needed only if backward compatibility with pybind11v2 is required.

    (Note that copyable_holder_caster and move_only_holder_caster are not documented, although they existed since 2017.)

v2.12#

NumPy support has been upgraded to support the 2.x series too. The two relevant changes are that:

  • dtype.flags() is now a uint64 and dtype.alignment() an ssize_t (and NumPy may return an larger than integer value for itemsize() in NumPy 2.x).

  • The long deprecated NumPy function PyArray_GetArrayParamsFromObject function is not available anymore.

Due to NumPy changes, you may experience difficulties updating to NumPy 2. Please see the NumPy 2 migration guide for details. For example, a more direct change could be that the default integer "int_" (and "uint") is now ssize_t and not long (affects 64bit windows).

If you want to only support NumPy 1.x for now and are having problems due to the two internal changes listed above, you can define PYBIND11_NUMPY_1_ONLY to disable the new support for now. Make sure you define this on all pybind11 compile units, since it could be a source of ODR violations if used inconsistently. This option will be removed in the future, so adapting your code is highly recommended.

v2.11#

  • The minimum version of CMake is now 3.5. A future version will likely move to requiring something like CMake 3.15. Note that CMake 3.27 is removing the long-deprecated support for FindPythonInterp if you set 3.27 as the minimum or maximum supported version. To prepare for that future, CMake 3.15+ using FindPython or setting PYBIND11_FINDPYTHON is highly recommended, otherwise pybind11 will automatically switch to using FindPython if FindPythonInterp is not available.

v2.9#

  • Any usage of the recently added py::make_simple_namespace should be converted to using py::module_::import("types").attr("SimpleNamespace") instead.

  • The use of _ in custom type casters can now be replaced with the more readable const_name instead. The old _ shortcut has been retained unless it is being used as a macro (like for gettext).

v2.7#

Before v2.7, py::str can hold PyUnicodeObject or PyBytesObject, and py::isinstance<str>() is true for both py::str and py::bytes. Starting with v2.7, py::str exclusively holds PyUnicodeObject (#2409), and py::isinstance<str>() is true only for py::str. To help in the transition of user code, the PYBIND11_STR_LEGACY_PERMISSIVE macro is provided as an escape hatch to go back to the legacy behavior. This macro will be removed in future releases. Two types of required fixes are expected to be common:

  • Accidental use of py::str instead of py::bytes, masked by the legacy behavior. These are probably very easy to fix, by changing from py::str to py::bytes.

  • Reliance on py::isinstance<str>(obj) being true for py::bytes. This is likely to be easy to fix in most cases by adding || py::isinstance<bytes>(obj), but a fix may be more involved, e.g. if py::isinstance<T> appears in a template. Such situations will require careful review and custom fixes.

v2.6#

Usage of the PYBIND11_OVERLOAD* macros and get_overload function should be replaced by PYBIND11_OVERRIDE* and get_override. In the future, the old macros may be deprecated and removed.

py::module has been renamed py::module_, but a backward compatible typedef has been included. This change was to avoid a language change in C++20 that requires unqualified module not be placed at the start of a logical line. Qualified usage is unaffected and the typedef will remain unless the C++ language rules change again.

The public constructors of py::module_ have been deprecated. Use PYBIND11_MODULE or module_::create_extension_module instead.

An error is now thrown when __init__ is forgotten on subclasses. This was incorrect before, but was not checked. Add a call to __init__ if it is missing.

A py::type_error is now thrown when casting to a subclass (like py::bytes from py::object) if the conversion is not valid. Make a valid conversion instead.

The undocumented h.get_type() method has been deprecated and replaced by py::type::of(h).

Enums now have a __str__ method pre-defined; if you want to override it, the simplest fix is to add the new py::prepend() tag when defining "__str__".

If __eq__ defined but not __hash__, __hash__ is now set to None, as in normal CPython. You should add __hash__ if you intended the class to be hashable, possibly using the new py::hash shortcut.

The constructors for py::array now always take signed integers for size, for consistency. This may lead to compiler warnings on some systems. Cast to py::ssize_t instead of std::size_t.

The tools/clang submodule and tools/mkdoc.py have been moved to a standalone package, pybind11-mkdoc. If you were using those tools, please use them via a pip install from the new location.

The pybind11 package on PyPI no longer fills the wheel “headers” slot - if you were using the headers from this slot, they are available by requesting the global extra, that is, pip install "pybind11[global]". (Most users will be unaffected, as the pybind11/include location is reported by python -m pybind11 --includes and pybind11.get_include() is still correct and has not changed since 2.5).

CMake support:#

The minimum required version of CMake is now 3.4. Several details of the CMake support have been deprecated; warnings will be shown if you need to change something. The changes are:

  • PYBIND11_CPP_STANDARD=<platform-flag> is deprecated, please use CMAKE_CXX_STANDARD=<number> instead, or any other valid CMake CXX or CUDA standard selection method, like target_compile_features.

  • If you do not request a standard, pybind11 targets will compile with the compiler default, but not less than C++11, instead of forcing C++14 always. If you depend on the old behavior, please use set(CMAKE_CXX_STANDARD 14 CACHE STRING "") instead.

  • Direct pybind11::module usage should always be accompanied by at least set(CMAKE_CXX_VISIBILITY_PRESET hidden) or similar - it used to try to manually force this compiler flag (but not correctly on all compilers or with CUDA).

  • pybind11_add_module’s SYSTEM argument is deprecated and does nothing; linking now behaves like other imported libraries consistently in both config and submodule mode, and behaves like a SYSTEM library by default.

  • If PYTHON_EXECUTABLE is not set, virtual environments (venv, virtualenv, and conda) are prioritized over the standard search (similar to the new FindPython mode).

In addition, the following changes may be of interest:

  • CMAKE_INTERPROCEDURAL_OPTIMIZATION will be respected by pybind11_add_module if set instead of linking to pybind11::lto or pybind11::thin_lto.

  • Using find_package(Python COMPONENTS Interpreter Development) before pybind11 will cause pybind11 to use the new Python mechanisms instead of its own custom search, based on a patched version of classic FindPythonInterp / FindPythonLibs. In the future, this may become the default. A recent (3.15+ or 3.18.2+) version of CMake is recommended.

v2.5#

The Python package now includes the headers as data in the package itself, as well as in the “headers” wheel slot. pybind11 --includes and pybind11.get_include() report the new location, which is always correct regardless of how pybind11 was installed, making the old user= argument meaningless. If you are not using the function to get the location already, you are encouraged to switch to the package location.

v2.2#

Deprecation of the PYBIND11_PLUGIN macro#

PYBIND11_MODULE is now the preferred way to create module entry points. The old macro emits a compile-time deprecation warning.

// old
PYBIND11_PLUGIN(example) {
    py::module m("example", "documentation string");

    m.def("add", [](int a, int b) { return a + b; });

    return m.ptr();
}

// new
PYBIND11_MODULE(example, m) {
    m.doc() = "documentation string"; // optional

    m.def("add", [](int a, int b) { return a + b; });
}

New API for defining custom constructors and pickling functions#

The old placement-new custom constructors have been deprecated. The new approach uses py::init() and factory functions to greatly improve type safety.

Placement-new can be called accidentally with an incompatible type (without any compiler errors or warnings), or it can initialize the same object multiple times if not careful with the Python-side __init__ calls. The new-style custom constructors prevent such mistakes. See Custom constructors for details.

// old -- deprecated (runtime warning shown only in debug mode)
py::class<Foo>(m, "Foo")
    .def("__init__", [](Foo &self, ...) {
        new (&self) Foo(...); // uses placement-new
    });

// new
py::class<Foo>(m, "Foo")
    .def(py::init([](...) { // Note: no `self` argument
        return new Foo(...); // return by raw pointer
        // or: return std::make_unique<Foo>(...); // return by holder
        // or: return Foo(...); // return by value (move constructor)
    }));

Mirroring the custom constructor changes, py::pickle() is now the preferred way to get and set object state. See Pickling support for details.

// old -- deprecated (runtime warning shown only in debug mode)
py::class<Foo>(m, "Foo")
    ...
    .def("__getstate__", [](const Foo &self) {
        return py::make_tuple(self.value1(), self.value2(), ...);
    })
    .def("__setstate__", [](Foo &self, py::tuple t) {
        new (&self) Foo(t[0].cast<std::string>(), ...);
    });

// new
py::class<Foo>(m, "Foo")
    ...
    .def(py::pickle(
        [](const Foo &self) { // __getstate__
            return py::make_tuple(self.value1(), self.value2(), ...); // unchanged
        },
        [](py::tuple t) { // __setstate__, note: no `self` argument
            return new Foo(t[0].cast<std::string>(), ...);
            // or: return std::make_unique<Foo>(...); // return by holder
            // or: return Foo(...); // return by value (move constructor)
        }
    ));

For both the constructors and pickling, warnings are shown at module initialization time (on import, not when the functions are called). They’re only visible when compiled in debug mode. Sample warning:

pybind11-bound class 'mymodule.Foo' is using an old-style placement-new '__init__'
which has been deprecated. See the upgrade guide in pybind11's docs.

Stricter enforcement of hidden symbol visibility for pybind11 modules#

pybind11 now tries to actively enforce hidden symbol visibility for modules. If you’re using either one of pybind11’s CMake or Python build systems (the two example repositories) and you haven’t been exporting any symbols, there’s nothing to be concerned about. All the changes have been done transparently in the background. If you were building manually or relied on specific default visibility, read on.

Setting default symbol visibility to hidden has always been recommended for pybind11 (see How can I create smaller binaries?). On Linux and macOS, hidden symbol visibility (in conjunction with the strip utility) yields much smaller module binaries. CPython’s extension docs also recommend hiding symbols by default, with the goal of avoiding symbol name clashes between modules. Starting with v2.2, pybind11 enforces this more strictly: (1) by declaring all symbols inside the pybind11 namespace as hidden and (2) by including the -fvisibility=hidden flag on Linux and macOS (only for extension modules, not for embedding the interpreter).

The namespace-scope hidden visibility is done automatically in pybind11’s headers and it’s generally transparent to users. It ensures that:

  • Modules compiled with different pybind11 versions don’t clash with each other.

  • Some new features, like py::module_local bindings, can work as intended.

The -fvisibility=hidden flag applies the same visibility to user bindings outside of the pybind11 namespace. It’s now set automatic by pybind11’s CMake and Python build systems, but this needs to be done manually by users of other build systems. Adding this flag:

  • Minimizes the chances of symbol conflicts between modules. E.g. if two unrelated modules were statically linked to different (ABI-incompatible) versions of the same third-party library, a symbol clash would be likely (and would end with unpredictable results).

  • Produces smaller binaries on Linux and macOS, as pointed out previously.

Within pybind11’s CMake build system, pybind11_add_module has always been setting the -fvisibility=hidden flag in release mode. From now on, it’s being applied unconditionally, even in debug mode and it can no longer be opted out of with the NO_EXTRAS option. The pybind11::module target now also adds this flag to its interface. The pybind11::embed target is unchanged.

The most significant change here is for the pybind11::module target. If you were previously relying on default visibility, i.e. if your Python module was doubling as a shared library with dependents, you’ll need to either export symbols manually (recommended for cross-platform libraries) or factor out the shared library (and have the Python module link to it like the other dependents). As a temporary workaround, you can also restore default visibility using the CMake code below, but this is not recommended in the long run:

target_link_libraries(mymodule PRIVATE pybind11::module)

add_library(restore_default_visibility INTERFACE)
target_compile_options(restore_default_visibility INTERFACE -fvisibility=default)
target_link_libraries(mymodule PRIVATE restore_default_visibility)

Local STL container bindings#

Previous pybind11 versions could only bind types globally – all pybind11 modules, even unrelated ones, would have access to the same exported types. However, this would also result in a conflict if two modules exported the same C++ type, which is especially problematic for very common types, e.g. std::vector<int>. Module-local class bindings were added to resolve this (see that section for a complete usage guide).

py::class_ still defaults to global bindings (because these types are usually unique across modules), however in order to avoid clashes of opaque types, py::bind_vector and py::bind_map will now bind STL containers as py::module_local if their elements are: builtins (int, float, etc.), not bound using py::class_, or bound as py::module_local. For example, this change allows multiple modules to bind std::vector<int> without causing conflicts. See Binding STL containers for more details.

When upgrading to this version, if you have multiple modules which depend on a single global binding of an STL container, note that all modules can still accept foreign py::module_local types in the direction of Python-to-C++. The locality only affects the C++-to-Python direction. If this is needed in multiple modules, you’ll need to either:

  • Add a copy of the same STL binding to all of the modules which need it.

  • Restore the global status of that single binding by marking it py::module_local(false).

The latter is an easy workaround, but in the long run it would be best to localize all common type bindings in order to avoid conflicts with third-party modules.

Negative strides for Python buffer objects and numpy arrays#

Support for negative strides required changing the integer type from unsigned to signed in the interfaces of py::buffer_info and py::array. If you have compiler warnings enabled, you may notice some new conversion warnings after upgrading. These can be resolved using static_cast.

Deprecation of some py::object APIs#

To compare py::object instances by pointer, you should now use obj1.is(obj2) which is equivalent to obj1 is obj2 in Python. Previously, pybind11 used operator== for this (obj1 == obj2), but that could be confusing and is now deprecated (so that it can eventually be replaced with proper rich object comparison in a future release).

For classes which inherit from py::object, borrowed and stolen were previously available as protected constructor tags. Now the types should be used directly instead: borrowed_t{} and stolen_t{} (#771).

Stricter compile-time error checking#

Some error checks have been moved from run time to compile time. Notably, automatic conversion of std::shared_ptr<T> is not possible when T is not directly registered with py::class_<T> (e.g. std::shared_ptr<int> or std::shared_ptr<std::vector<T>> are not automatically convertible). Attempting to bind a function with such arguments now results in a compile-time error instead of waiting to fail at run time.

py::init<...>() constructor definitions are also stricter and now prevent bindings which could cause unexpected behavior:

struct Example {
    Example(int &);
};

py::class_<Example>(m, "Example")
    .def(py::init<int &>()); // OK, exact match
    // .def(py::init<int>()); // compile-time error, mismatch

A non-const lvalue reference is not allowed to bind to an rvalue. However, note that a constructor taking const T & can still be registered using py::init<T>() because a const lvalue reference can bind to an rvalue.

v2.1#

Minimum compiler versions are enforced at compile time#

The minimums also apply to v2.0 but the check is now explicit and a compile-time error is raised if the compiler does not meet the requirements:

  • GCC >= 4.8

  • clang >= 3.3 (appleclang >= 5.0)

  • MSVC >= 2015u3

  • Intel C++ >= 15.0

The py::metaclass attribute is not required for static properties#

Binding classes with static properties is now possible by default. The zero-parameter version of py::metaclass() is deprecated. However, a new one-parameter py::metaclass(python_type) version was added for rare cases when a custom metaclass is needed to override pybind11’s default.

// old -- emits a deprecation warning
py::class_<Foo>(m, "Foo", py::metaclass())
    .def_property_readonly_static("foo", ...);

// new -- static properties work without the attribute
py::class_<Foo>(m, "Foo")
    .def_property_readonly_static("foo", ...);

// new -- advanced feature, override pybind11's default metaclass
py::class_<Bar>(m, "Bar", py::metaclass(custom_python_type))
    ...

v2.0#

Breaking changes in py::class_#

These changes were necessary to make type definitions in pybind11 future-proof, to support PyPy via its cpyext mechanism (#527), and to improve efficiency (rev. 86d825).

  1. Declarations of types that provide access via the buffer protocol must now include the py::buffer_protocol() annotation as an argument to the py::class_ constructor.

    py::class_<Matrix>("Matrix", py::buffer_protocol())
    .def(py::init<...>())
    .def_buffer(...);

  2. Classes which include static properties (e.g. def_readwrite_static()) must now include the py::metaclass() attribute. Note: this requirement has since been removed in v2.1. If you’re upgrading from 1.x, it’s recommended to skip directly to v2.1 or newer.

  3. This version of pybind11 uses a redesigned mechanism for instantiating trampoline classes that are used to override virtual methods from within Python. This led to the following user-visible syntax change:

    // old v1.x syntax
py::class_<TrampolineClass>("MyClass")
    .alias<MyClass>()
    ...

// new v2.x syntax
py::class_<MyClass, TrampolineClass>("MyClass")
    ...

    Importantly, both the original and the trampoline class are now specified as arguments to the py::class_ template, and the alias<..>() call is gone. The new scheme has zero overhead in cases when Python doesn’t override any functions of the underlying C++ class. rev. 86d825.

    The class type must be the first template argument given to py::class_ while the trampoline can be mixed in arbitrary order with other arguments (see the following section).

Deprecation of the py::base<T>() attribute#

py::base<T>() was deprecated in favor of specifying T as a template argument to py::class_. This new syntax also supports multiple inheritance. Note that, while the type being exported must be the first argument in the py::class_<Class, ...> template, the order of the following types (bases, holder and/or trampoline) is not important.

// old v1.x
py::class_<Derived>("Derived", py::base<Base>());

// new v2.x
py::class_<Derived, Base>("Derived");

// new -- multiple inheritance
py::class_<Derived, Base1, Base2>("Derived");

// new -- apart from `Derived` the argument order can be arbitrary
py::class_<Derived, Base1, Holder, Base2, Trampoline>("Derived");

Out-of-the-box support for std::shared_ptr#

The relevant type caster is now built in, so it’s no longer necessary to include a declaration of the form:

PYBIND11_DECLARE_HOLDER_TYPE(T, std::shared_ptr<T>)

Continuing to do so won’t cause an error or even a deprecation warning, but it’s completely redundant.

Deprecation of a few py::object APIs#

All of the old-style calls emit deprecation warnings.

Old syntax

New syntax

obj.call(args...)

obj(args...)

obj.str()

py::str(obj)

auto l = py::list(obj); l.check()

py::isinstance<py::list>(obj)

py::object(ptr, true)

py::reinterpret_borrow<py::object>(ptr)

py::object(ptr, false)

py::reinterpret_steal<py::object>(ptr)

if (obj.attr("foo"))

if (py::hasattr(obj, "foo"))

if (obj["bar"])

if (obj.contains("bar"))