Movatterモバイル変換


[0]ホーム

URL:


ContentsMenuExpandLight modeDark modeAuto light/dark mode
pybind11 documentation
pybind11 documentation

The Basics

Advanced Topics

Extra Information

Back to top

Classes#

This section presents advanced binding code for classes and it is assumedthat you are already familiar with the basics fromObject-oriented code.

Overriding virtual functions in Python#

Suppose that a C++ class or interface has a virtual function that we’d liketo override from within Python (we’ll focus on the classAnimal;Dog isgiven as a specific example of how one would do this with traditional C++code).

classAnimal{public:virtual~Animal(){}virtualstd::stringgo(intn_times)=0;};classDog:publicAnimal{public:std::stringgo(intn_times)override{std::stringresult;for(inti=0;i<n_times;++i)result+="woof! ";returnresult;}};

Let’s also suppose that we are given a plain function which calls thefunctiongo() on an arbitraryAnimal instance.

std::stringcall_go(Animal*animal){returnanimal->go(3);}

Normally, the binding code for these classes would look as follows:

PYBIND11_MODULE(example,m){py::class_<Animal>(m,"Animal").def("go",&Animal::go);py::class_<Dog,Animal>(m,"Dog").def(py::init<>());m.def("call_go",&call_go);}

However, these bindings are impossible to extend:Animal is notconstructible, and we clearly require some kind of “trampoline” thatredirects virtual calls back to Python.

Defining a new type ofAnimal from within Python is possible but requires ahelper class that is defined as follows:

classPyAnimal:publicAnimal,py::trampoline_self_life_support{public:/* Inherit the constructors */usingAnimal::Animal;/* Trampoline (need one for each virtual function) */std::stringgo(intn_times)override{PYBIND11_OVERRIDE_PURE(std::string,/* Return type */Animal,/* Parent class */go,/* Name of function in C++ (must match Python name) */n_times/* Argument(s) */);}};

Thepy::trampoline_self_life_support base class is needed to ensurethat astd::unique_ptr can safely be passed between Python and C++. Tohelp you steer clear of notorious pitfalls (e.g. inheritance slicing),pybind11 enforces that trampoline classes inherit frompy::trampoline_self_life_support if used in in combination withpy::smart_holder.

Note

For completeness, the base class has no effect if a holder other thanpy::smart_holder used, including the defaultstd::unique_ptr<T>.To avoid confusion, pybind11 will fail to compile bindings that combinepy::trampoline_self_life_support with a holder other thanpy::smart_holder.

Please think twice, though, before deciding to not use the saferpy::smart_holder. The pitfalls associated with avoiding it are veryreal, and the overhead for using it is very likely in the noise.

The macroPYBIND11_OVERRIDE_PURE should be used for pure virtualfunctions, andPYBIND11_OVERRIDE should be used for functions which havea default implementation. There are also two alternate macrosPYBIND11_OVERRIDE_PURE_NAME andPYBIND11_OVERRIDE_NAME whichtake a string-valued name argument between theParent class andName of thefunction slots, which defines the name of function in Python. This is requiredwhen the C++ and Python versions of thefunction have different names, e.g.operator() vs__call__.

The binding code also needs a few minor adaptations (highlighted):

PYBIND11_MODULE(example,m){py::class_<Animal,PyAnimal/* <--- trampoline */,py::smart_holder>(m,"Animal").def(py::init<>()).def("go",&Animal::go);py::class_<Dog,Animal,py::smart_holder>(m,"Dog").def(py::init<>());m.def("call_go",&call_go);}

Importantly, pybind11 is made aware of the trampoline helper class byspecifying it as an extra template argument topy::class_. (This can alsobe combined with other template arguments such as a custom holder type; theorder of template types does not matter). Following this, we are able todefine a constructor as usual.

Bindings should be made against the actual class, not the trampoline helper class.

py::class_<Animal,PyAnimal/* <--- trampoline */,py::smart_holder>(m,"Animal");.def(py::init<>()).def("go",&Animal::go);/* <--- DO NOT USE &PyAnimal::go HERE */

Note, however, that the above is sufficient for allowing python classes toextendAnimal, but notDog: seeCombining virtual functions and inheritance for thenecessary steps required to providing proper overriding support for inheritedclasses.

The Python session below shows how to overrideAnimal::go and invoke it viaa virtual method call.

>>>fromexampleimport*>>>d=Dog()>>>call_go(d)'woof! woof! woof! '>>>classCat(Animal):...defgo(self,n_times):...return"meow! "*n_times...>>>c=Cat()>>>call_go(c)'meow! meow! meow! '

If you are defining a custom constructor in a derived Python class, youmustensure that you explicitly call the bound C++ constructor using__init__,regardless of whether it is a default constructor or not. Otherwise, thememory for the C++ portion of the instance will be left uninitialized, whichwill generally leave the C++ instance in an invalid state and cause undefinedbehavior if the C++ instance is subsequently used.

Changed in version 2.6:The default pybind11 metaclass will throw aTypeError when it detectsthat__init__ was not called by a derived class.

Here is an example:

classDachshund(Dog):def__init__(self,name):Dog.__init__(self)# Without this, a TypeError is raised.self.name=namedefbark(self):return"yap!"

Note that a direct__init__ constructorshould be called, andsuper()should not be used. For simple cases of linear inheritance,super()may work, but once you begin mixing Python and C++ multiple inheritance,things will fall apart due to differences between Python’s MRO and C++’smechanisms.

Please take a look at theGeneral notes regarding convenience macros before using this feature.

Note

When the overridden type returns a reference or pointer to a type thatpybind11 converts from Python (for example, numeric values, std::string,and other built-in value-converting types), there are some limitations tobe aware of:

  • because in these cases there is no C++ variable to reference (the valueis stored in the referenced Python variable), pybind11 provides one inthe PYBIND11_OVERRIDE macros (when needed) with static storage duration.Note that this means that invoking the overridden method onanyinstance will change the referenced value stored inall instances ofthat type.

  • Attempts to modify a non-const reference will not have the desiredeffect: it will change only the static cache variable, but this changewill not propagate to underlying Python instance, and the change will bereplaced the next time the override is invoked.

Warning

ThePYBIND11_OVERRIDE and accompanying macros used to be calledPYBIND11_OVERLOAD up until pybind11 v2.5.0, andget_override()used to be calledget_overload. This naming was corrected and the oldermacro and function names may soon be deprecated, in order to reduceconfusion with overloaded functions and methods andpy::overload_cast(seeObject-oriented code).

See also

The filetests/test_virtual_functions.cpp contains a completeexample that demonstrates how to override virtual functions using pybind11in more detail.

Combining virtual functions and inheritance#

When combining virtual methods with inheritance, you need to be sure to providean override for each method for which you want to allow overrides from derivedpython classes. For example, suppose we extend the aboveAnimal/Dogexample as follows:

classAnimal{public:virtualstd::stringgo(intn_times)=0;virtualstd::stringname(){return"unknown";}};classDog:publicAnimal{public:std::stringgo(intn_times)override{std::stringresult;for(inti=0;i<n_times;++i)result+=bark()+" ";returnresult;}virtualstd::stringbark(){return"woof!";}};

then the trampoline class forAnimal must, as described in the previoussection, overridego() andname(), but in order to allow python code toinherit properly fromDog, we also need a trampoline class forDog thatoverrides both the addedbark() methodand thego() andname()methods inherited fromAnimal (even thoughDog doesn’t directlyoverride thename() method):

classPyAnimal:publicAnimal,py::trampoline_self_life_support{public:usingAnimal::Animal;// Inherit constructorsstd::stringgo(intn_times)override{PYBIND11_OVERRIDE_PURE(std::string,Animal,go,n_times);}std::stringname()override{PYBIND11_OVERRIDE(std::string,Animal,name,);}};classPyDog:publicDog,py::trampoline_self_life_support{public:usingDog::Dog;// Inherit constructorsstd::stringgo(intn_times)override{PYBIND11_OVERRIDE(std::string,Dog,go,n_times);}std::stringname()override{PYBIND11_OVERRIDE(std::string,Dog,name,);}std::stringbark()override{PYBIND11_OVERRIDE(std::string,Dog,bark,);}};

Note

Note the trailing commas in thePYBIND11_OVERRIDE calls toname()andbark(). These are needed to portably implement a trampoline for afunction that does not take any arguments. For functions that takea nonzero number of arguments, the trailing comma must be omitted.

A registered class derived from a pybind11-registered class with virtualmethods requires a similar trampoline class,even if it doesn’t explicitlydeclare or override any virtual methods itself:

classHusky:publicDog{};classPyHusky:publicHusky,py::trampoline_self_life_support{public:usingHusky::Husky;// Inherit constructorsstd::stringgo(intn_times)override{PYBIND11_OVERRIDE_PURE(std::string,Husky,go,n_times);}std::stringname()override{PYBIND11_OVERRIDE(std::string,Husky,name,);}std::stringbark()override{PYBIND11_OVERRIDE(std::string,Husky,bark,);}};

There is, however, a technique that can be used to avoid this duplication(which can be especially helpful for a base class with several virtualmethods). The technique involves using template trampoline classes, asfollows:

template<classAnimalBase=Animal>classPyAnimal:publicAnimalBase,py::trampoline_self_life_support{public:usingAnimalBase::AnimalBase;// Inherit constructorsstd::stringgo(intn_times)override{PYBIND11_OVERRIDE_PURE(std::string,AnimalBase,go,n_times);}std::stringname()override{PYBIND11_OVERRIDE(std::string,AnimalBase,name,);}};template<classDogBase=Dog>classPyDog:publicPyAnimal<DogBase>,py::trampoline_self_life_support{public:usingPyAnimal<DogBase>::PyAnimal;// Inherit constructors// Override PyAnimal's pure virtual go() with a non-pure one:std::stringgo(intn_times)override{PYBIND11_OVERRIDE(std::string,DogBase,go,n_times);}std::stringbark()override{PYBIND11_OVERRIDE(std::string,DogBase,bark,);}};

This technique has the advantage of requiring just one trampoline method to bedeclared per virtual method and pure virtual method override. It does,however, require the compiler to generate at least as many methods (andpossibly more, if both pure virtual and overridden pure virtual methods areexposed, as above).

The classes are then registered with pybind11 using:

py::class_<Animal,PyAnimal<>,py::smart_holder>animal(m,"Animal");py::class_<Dog,Animal,PyDog<>,py::smart_holder>dog(m,"Dog");py::class_<Husky,Dog,PyDog<Husky>,py::smart_holder>husky(m,"Husky");// ... add animal, dog, husky definitions

Note thatHusky did not require a dedicated trampoline template class atall, since it neither declares any new virtual methods nor provides any purevirtual method implementations.

With either the repeated-virtuals or templated trampoline methods in place, youcan now create a python class that inherits fromDog:

classShihTzu(Dog):defbark(self):return"yip!"

See also

See the filetests/test_virtual_functions.cpp for complete examplesusing both the duplication and templated trampoline approaches.

Extended trampoline class functionality#

Forced trampoline class initialisation#

The trampoline classes described in the previous sections are, by default, onlyinitialized when needed. More specifically, they are initialized when a pythonclass actually inherits from a registered type (instead of merely creating aninstance of the registered type), or when a registered constructor is onlyvalid for the trampoline class but not the registered class. This is primarilyfor performance reasons: when the trampoline class is not needed for anythingexcept virtual method dispatching, not initializing the trampoline classimproves performance by avoiding needing to do a run-time check to see if theinheriting python instance has an overridden method.

Sometimes, however, it is useful to always initialize a trampoline class as anintermediate class that does more than just handle virtual method dispatching.For example, such a class might perform extra class initialization, extradestruction operations, and might define new members and methods to enable amore python-like interface to a class.

In order to tell pybind11 that it shouldalways initialize the trampolineclass when creating new instances of a type, the class constructors should bedeclared usingpy::init_alias<Args,...>() instead of the usualpy::init<Args,...>(). This forces construction via the trampoline class,ensuring member initialization and (eventual) destruction.

See also

See the filetests/test_virtual_functions.cpp for complete examplesshowing both normal and forced trampoline instantiation.

Different method signatures#

The macro’s introduced inOverriding virtual functions in Python cover most of the standarduse cases when exposing C++ classes to Python. Sometimes it is hard or unwieldyto create a direct one-on-one mapping between the arguments and method returntype.

An example would be when the C++ signature contains output arguments usingreferences (See alsoLimitations involving reference arguments). Another way of solvingthis is to use the method body of the trampoline class to do conversions to theinput and return of the Python method.

The main building block to do so is theget_override(), this functionallows retrieving a method implemented in Python from within the trampoline’smethods. Consider for example a C++ method which has the signatureboolmyMethod(int32_t&value), where the return indicates whethersomething should be done with thevalue. This can be made convenient on thePython side by allowing the Python function to returnNone or anint:

boolMyClass::myMethod(int32_t&value){pybind11::gil_scoped_acquiregil;// Acquire the GIL while in this scope.// Try to look up the overridden method on the Python side.pybind11::functionoverride=pybind11::get_override(this,"myMethod");if(override){// method is foundautoobj=override(value);// Call the Python function.if(py::isinstance<py::int_>(obj)){// check if it returned a Python integer typevalue=obj.cast<int32_t>();// Cast it and assign it to the value.returntrue;// Return true; value should be used.}else{returnfalse;// Python returned none, return false.}}returnfalse;// Alternatively return MyClass::myMethod(value);}

Avoiding Inheritance Slicing andstd::weak_ptr surprises#

When working with classes that use virtual functions and are subclassedin Python, special care must be taken when converting Python objects tostd::shared_ptr<T>. Depending on whether the class uses a plainstd::shared_ptr holder orpy::smart_holder, the resultingshared_ptr may either allow inheritance slicing or lead to potentiallysurprising behavior when constructingstd::weak_ptr instances.

This section explains howstd::shared_ptr andpy::smart_holder manageobject lifetimes differently, how these differences affect trampoline-derivedobjects, and what options are available to achieve the situation-specificdesired behavior.

When usingstd::shared_ptr as the holder type, converting a Python objectto astd::shared_ptr<T> (e.g.,obj.cast<std::shared_ptr<T>>(), or simplypassing the Python object as an argument to a.def()-ed function) returnsashared_ptr that shares ownership with the originalclass_ holder,usually preserving object lifetime. However, for Python classes that derive froma trampoline, if the Python object is destroyed, only the base C++ object mayremain alive, leading to inheritance slicing(see#1333).

In contrast, withpy::smart_holder, converting a Python object toastd::shared_ptr<T> returns a newshared_ptr with an independentcontrol block that keeps the derived Python object alive. This avoidsinheritance slicing but can lead to unintended behavior when creatingstd::weak_ptr instances(see#5623).

If it is necessary to obtain astd::weak_ptr that shares the control blockwith thesmart_holder—at the cost of reintroducing potential inheritanceslicing—you can usepy::potentially_slicing_weak_ptr<T>(obj).

When precise lifetime management of derived Python objects is important,using a Python-sideweakref is the most reliable approach, as it avoidsboth inheritance slicing and unintended interactions withstd::weak_ptrsemantics in C++.

See also

  • potentially_slicing_weak_ptr() C++ documentation

  • tests/test_potentially_slicing_weak_ptr.cpp

Custom constructors#

The syntax for binding constructors was previously introduced, but it onlyworks when a constructor of the appropriate arguments actually exists on theC++ side. To extend this to more general cases, pybind11 makes it possibleto bind factory functions as constructors. For example, suppose you have aclass like this:

classExample{private:Example(int);// private constructorpublic:// Factory function:staticExamplecreate(inta){returnExample(a);}};py::class_<Example>(m,"Example").def(py::init(&Example::create));

While it is possible to create a straightforward binding of the staticcreate method, it may sometimes be preferable to expose it as a constructoron the Python side. This can be accomplished by calling.def(py::init(...))with the function reference returning the new instance passed as an argument.It is also possible to use this approach to bind a function returning a newinstance by raw pointer or by the holder (e.g.std::unique_ptr).

The following example shows the different approaches:

classExample{private:Example(int);// private constructorpublic:// Factory function - returned by value:staticExamplecreate(inta){returnExample(a);}// These constructors are publicly callable:Example(double);Example(int,int);Example(std::string);};py::class_<Example>(m,"Example")// Bind the factory function as a constructor:.def(py::init(&Example::create))// Bind a lambda function returning a pointer wrapped in a holder:.def(py::init([](std::stringarg){returnstd::unique_ptr<Example>(newExample(arg));}))// Return a raw pointer:.def(py::init([](inta,intb){returnnewExample(a,b);}))// You can mix the above with regular C++ constructor bindings as well:.def(py::init<double>());

When the constructor is invoked from Python, pybind11 will call the factoryfunction and store the resulting C++ instance in the Python instance.

When combining factory functions constructors withvirtual functiontrampolines there are two approaches. The first is toadd a constructor to the alias class that takes a base value byrvalue-reference. If such a constructor is available, it will be used toconstruct an alias instance from the value returned by the factory function.The second option is to provide two factory functions topy::init(): thefirst will be invoked when no alias class is required (i.e. when the class isbeing used but not inherited from in Python), and the second will be invokedwhen an alias is required.

You can also specify a single factory function that always returns an aliasinstance: this will result in behaviour similar topy::init_alias<...>(),as described in theextended trampoline class documentation.

The following example shows the different factory approaches for a class withan alias:

#include<pybind11/factory.h>classExample{public:// ...virtual~Example()=default;};classPyExample:publicExample,py::trampoline_self_life_support{public:usingExample::Example;PyExample(Example&&base):Example(std::move(base)){}};py::class_<Example,PyExample,py::smart_holder>(m,"Example")// Returns an Example pointer.  If a PyExample is needed, the Example// instance will be moved via the extra constructor in PyExample, above..def(py::init([](){returnnewExample();}))// Two callbacks:.def(py::init([](){returnnewExample();}/* no alias needed */,[](){returnnewPyExample();}/* alias needed */))// *Always* returns an alias instance (like py::init_alias<>()).def(py::init([](){returnnewPyExample();}));

Brace initialization#

pybind11::init<> internally uses C++11 brace initialization to call theconstructor of the target class. This means that it can be used to bindimplicit constructors as well:

structAggregate{inta;std::stringb;};py::class_<Aggregate>(m,"Aggregate").def(py::init<int,conststd::string&>());

Note

Note that brace initialization preferentially invokes constructor overloadstaking astd::initializer_list. In the rare event that this causes anissue, you can work around it by usingpy::init(...) with a lambdafunction that constructs the new object as desired.

Non-public destructors#

If a class has a private or protected destructor (as might e.g. be the case ina singleton pattern), a compile error will occur when creating bindings viapybind11. The underlying issue is that thestd::unique_ptr holder type thatis responsible for managing the lifetime of instances will reference thedestructor even if no deallocations ever take place. In order to expose classeswith private or protected destructors, it is possible to override the holdertype via a holder type argument topy::class_. Pybind11 provides a helperclasspy::nodelete that disables any destructor invocations. In this case,it is crucial that instances are deallocated on the C++ side to avoid memoryleaks.

/* ... definition ... */classMyClass{private:~MyClass(){}};/* ... binding code ... */py::class_<MyClass,std::unique_ptr<MyClass,py::nodelete>>(m,"MyClass").def(py::init<>())

Destructors that call Python#

If a Python function is invoked from a C++ destructor, an exception may be thrownof typeerror_already_set. If this error is thrown out of a class destructor,std::terminate() will be called, terminating the process. Class destructorsmust catch all exceptions of typeerror_already_set to discard the Pythonexception usingerror_already_set::discard_as_unraisable().

Every Python function should be treated aspossibly throwing. When a Python generatorstops yielding items, Python will throw aStopIteration exception, which can passthough C++ destructors if the generator’s stack frame holds the last reference to C++objects.

For more information, seethe documentation on exceptions.

classMyClass{public:~MyClass(){try{py::print("Even printing is dangerous in a destructor");py::exec("raise ValueError('This is an unraisable exception')");}catch(py::error_already_set&e){// error_context should be information about where/why the occurred,// e.g. use __func__ to get the name of the current functione.discard_as_unraisable(__func__);}}};

Note

pybind11 does not support C++ destructors markednoexcept(false).

New in version 2.6.

Implicit conversions#

Suppose that instances of two typesA andB are used in a project, andthat anA can easily be converted into an instance of typeB (examples of thiscould be a fixed and an arbitrary precision number type).

py::class_<A>(m,"A")/// ... members ...py::class_<B>(m,"B").def(py::init<A>())/// ... members ...m.def("func",[](constB&){/* .... */});

To invoke the functionfunc using a variablea containing anAinstance, we’d have to writefunc(B(a)) in Python. On the other hand, C++will automatically apply an implicit type conversion, which makes it possibleto directly writefunc(a).

In this situation (i.e. whereB has a constructor that converts fromA), the following statement enables similar implicit conversions on thePython side:

py::implicitly_convertible<A,B>();

Note

Implicit conversions fromA toB only work whenB is a customdata type that is exposed to Python via pybind11.

To prevent runaway recursion, implicit conversions are non-reentrant: animplicit conversion invoked as part of another implicit conversion of thesame type (i.e. fromA toB) will fail.

Static properties#

The section onInstance and static fields discussed the creation of instance propertiesthat are implemented in terms of C++ getters and setters.

Static properties can also be created in a similar way to expose getters andsetters of static class attributes. Note that the implicitself argumentalso exists in this case and is used to pass the Pythontype subclassinstance. This parameter will often not be needed by the C++ side, and thefollowing example illustrates how to instantiate a lambda getter functionthat ignores it:

py::class_<Foo>(m,"Foo").def_property_readonly_static("foo",[](py::object/* self */){returnFoo();});

Operator overloading#

Suppose that we’re given the followingVector2 class with a vector additionand scalar multiplication operation, all implemented using overloaded operatorsin C++.

classVector2{public:Vector2(floatx,floaty):x(x),y(y){}Vector2operator+(constVector2&v)const{returnVector2(x+v.x,y+v.y);}Vector2operator*(floatvalue)const{returnVector2(x*value,y*value);}Vector2&operator+=(constVector2&v){x+=v.x;y+=v.y;return*this;}Vector2&operator*=(floatv){x*=v;y*=v;return*this;}friendVector2operator*(floatf,constVector2&v){returnVector2(f*v.x,f*v.y);}std::stringtoString()const{return"["+std::to_string(x)+", "+std::to_string(y)+"]";}private:floatx,y;};

The following snippet shows how the above operators can be conveniently exposedto Python.

#include<pybind11/operators.h>PYBIND11_MODULE(example,m){py::class_<Vector2>(m,"Vector2").def(py::init<float,float>()).def(py::self+py::self).def(py::self+=py::self).def(py::self*=float()).def(float()*py::self).def(py::self*float()).def(-py::self).def("__repr__",&Vector2::toString);}

Note that a line like

.def(py::self*float())

is really just short hand notation for

.def("__mul__",[](constVector2&a,floatb){returna*b;},py::is_operator())

This can be useful for exposing additional operators that don’t exist on theC++ side, or to perform other types of customization. Thepy::is_operatorflag marker is needed to inform pybind11 that this is an operator, whichreturnsNotImplemented when invoked with incompatible arguments rather thanthrowing a type error.

Note

To use the more convenientpy::self notation, the additionalheader filepybind11/operators.h must be included.

See also

The filetests/test_operator_overloading.cpp contains acomplete example that demonstrates how to work with overloaded operators inmore detail.

Pickling support#

Python’spickle module provides a powerful facility to serialize andde-serialize a Python object graph into a binary data stream. To pickle andunpickle C++ classes using pybind11, apy::pickle() definition must beprovided. Suppose the class in question has the following signature:

classPickleable{public:Pickleable(conststd::string&value):m_value(value){}conststd::string&value()const{returnm_value;}voidsetExtra(intextra){m_extra=extra;}intextra()const{returnm_extra;}private:std::stringm_value;intm_extra=0;};

Pickling support in Python is enabled by defining the__setstate__ and__getstate__ methods[1]. For pybind11 classes, usepy::pickle()to bind these two functions:

py::class_<Pickleable>(m,"Pickleable").def(py::init<std::string>()).def("value",&Pickleable::value).def("extra",&Pickleable::extra).def("setExtra",&Pickleable::setExtra).def(py::pickle([](constPickleable&p){// __getstate__/* Return a tuple that fully encodes the state of the object */returnpy::make_tuple(p.value(),p.extra());},[](py::tuplet){// __setstate__if(t.size()!=2)throwstd::runtime_error("Invalid state!");/* Create a new C++ instance */Pickleablep(t[0].cast<std::string>());/* Assign any additional state */p.setExtra(t[1].cast<int>());returnp;}));

The__setstate__ part of thepy::pickle() definition follows the samerules as the single-argument version ofpy::init(). The return type can bea value, pointer or holder type. SeeCustom constructors for details.

An instance can now be pickled as follows:

importpicklep=Pickleable("test_value")p.setExtra(15)data=pickle.dumps(p)

Note

If given, the second argument todumps must be 2 or larger - 0 and 1 arenot supported. Newer versions are also fine; for instance, specify-1 toalways use the latest available version. Beware: failure to follow theseinstructions will cause important pybind11 memory allocation routines to beskipped during unpickling, which will likely lead to memory corruptionand/or segmentation faults.

See also

The filetests/test_pickling.cpp contains a complete examplethat demonstrates how to pickle and unpickle types using pybind11 in moredetail.

[1]

http://docs.python.org/3/library/pickle.html#pickling-class-instances

Deepcopy support#

Python normally uses references in assignments. Sometimes a real copy is neededto prevent changing all copies. Thecopy module[2] provides thesecapabilities.

A class with pickle support is automatically also (deep)copycompatible. However, performance can be improved by adding custom__copy__ and__deepcopy__ methods.

For simple classes (deep)copy can be enabled by using the copy constructor,which should look as follows:

py::class_<Copyable>(m,"Copyable").def("__copy__",[](constCopyable&self){returnCopyable(self);}).def("__deepcopy__",[](constCopyable&self,py::dict){returnCopyable(self);},"memo"_a);

Note

Dynamic attributes will not be copied in this example.

[2]

https://docs.python.org/3/library/copy.html

Multiple Inheritance#

pybind11 can create bindings for types that derive from multiple base types(aka.multiple inheritance). To do so, specify all bases in the templatearguments of thepy::class_ declaration:

py::class_<MyType,BaseType1,BaseType2,BaseType3>(m,"MyType")...

The base types can be specified in arbitrary order, and they can even beinterspersed with alias types and holder types (discussed earlier in thisdocument)—pybind11 will automatically find out which is which. The onlyrequirement is that the first template argument is the type to be declared.

It is also permitted to inherit multiply from exported C++ classes in Python,as well as inheriting from multiple Python and/or pybind11-exported classes.

There is one caveat regarding the implementation of this feature:

When only one base type is specified for a C++ type that actually has multiplebases, pybind11 will assume that it does not participate in multipleinheritance, which can lead to undefined behavior. In such cases, add the tagmultiple_inheritance to the class constructor:

py::class_<MyType,BaseType2>(m,"MyType",py::multiple_inheritance());

The tag is redundant and does not need to be specified when multiple base typesare listed.

Module-local class bindings#

When creating a binding for a class, pybind11 by default makes that binding“global” across modules. What this means is that a type defined in one modulecan be returned from any module resulting in the same Python type. Forexample, this allows the following:

// In the module1.cpp binding code for module1:py::class_<Pet>(m,"Pet").def(py::init<std::string>()).def_readonly("name",&Pet::name);
// In the module2.cpp binding code for module2:m.def("create_pet",[](std::stringname){returnnewPet(name);});
>>>frommodule1importPet>>>frommodule2importcreate_pet>>>pet1=Pet("Kitty")>>>pet2=create_pet("Doggy")>>>pet2.name()'Doggy'

When writing binding code for a library, this is usually desirable: thisallows, for example, splitting up a complex library into multiple Pythonmodules.

In some cases, however, this can cause conflicts. For example, suppose twounrelated modules make use of an external C++ library and each provide custombindings for one of that library’s classes. This will result in an error whena Python program attempts to import both modules (directly or indirectly)because of conflicting definitions on the external type:

// dogs.cpp// Binding for external library class:py::class_<pets::Pet>(m,"Pet").def("name",&pets::Pet::name);// Binding for local extension class:py::class_<Dog,pets::Pet>(m,"Dog").def(py::init<std::string>());
// cats.cpp, in a completely separate project from the above dogs.cpp.// Binding for external library class:py::class_<pets::Pet>(m,"Pet").def("get_name",&pets::Pet::name);// Binding for local extending class:py::class_<Cat,pets::Pet>(m,"Cat").def(py::init<std::string>());
>>>importcats>>>importdogsTraceback (most recent call last):  File"<stdin>", line1, in<module>ImportError:generic_type: type "Pet" is already registered!

To get around this, you can tell pybind11 to keep the external class bindinglocalized to the module by passing thepy::module_local() attribute intothepy::class_ constructor:

// Pet binding in dogs.cpp:py::class_<pets::Pet>(m,"Pet",py::module_local()).def("name",&pets::Pet::name);
// Pet binding in cats.cpp:py::class_<pets::Pet>(m,"Pet",py::module_local()).def("get_name",&pets::Pet::name);

This makes the Python-sidedogs.Pet andcats.Pet into distinct classes,avoiding the conflict and allowing both modules to be loaded. C++ code in thedogs module that casts or returns aPet instance will result in adogs.Pet Python instance, while C++ code in thecats module will resultin acats.Pet Python instance.

This does come with two caveats, however: First, external modules cannot returnor cast aPet instance to Python (unless they also provide their own localbindings). Second, from the Python point of view they are two distinct classes.

Note that the locality only applies in the C++ -> Python direction. Whenpassing such apy::module_local type into a C++ function, the module-localclasses are still considered. This means that if the following function isadded to any module (including but not limited to thecats anddogsmodules above) it will be callable with either adogs.Pet orcats.Petargument:

m.def("pet_name",[](constpets::Pet&pet){returnpet.name();});

For example, suppose the above function is added to each ofcats.cpp,dogs.cpp andfrogs.cpp (wherefrogs.cpp is some other module thatdoesnot bindPets at all).

>>>importcats,dogs,frogs# No error because of the added py::module_local()>>>mycat,mydog=cats.Cat("Fluffy"),dogs.Dog("Rover")>>>(cats.pet_name(mycat),dogs.pet_name(mydog))('Fluffy', 'Rover')>>>(cats.pet_name(mydog),dogs.pet_name(mycat),frogs.pet_name(mycat))('Rover', 'Fluffy', 'Fluffy')

It is possible to usepy::module_local() registrations in one module evenif another module registers the same type globally: within the module with themodule-local definition, all C++ instances will be cast to the associated boundPython type. In other modules any such values are converted to the globalPython type created elsewhere.

Note

STL bindings (as provided via the optionalpybind11/stl_bind.hheader) applypy::module_local by default when the bound type mightconflict with other modules; seeBinding STL containers for details.

Note

The localization of the bound types is actually tied to the shared objector binary generated by the compiler/linker. For typical modules createdwithPYBIND11_MODULE(), this distinction is not significant. It ispossible, however, whenEmbedding the interpreter to embed multiple modules in thesame binary (seeAdding embedded modules). In such a case, thelocalization will apply across all embedded modules within the same binary.

See also

The filetests/test_local_bindings.cpp contains additional examplesthat demonstrate howpy::module_local() works.

Binding protected member functions#

It’s normally not possible to exposeprotected member functions to Python:

classA{protected:intfoo()const{return42;}};py::class_<A>(m,"A").def("foo",&A::foo);// error: 'foo' is a protected member of 'A'

On one hand, this is good because non-public members aren’t meant to beaccessed from the outside. But we may want to make use ofprotectedfunctions in derived Python classes.

The following pattern makes this possible:

classA{protected:intfoo()const{return42;}};classPublicist:publicA{// helper type for exposing protected functionspublic:usingA::foo;// inherited with different access modifier};py::class_<A>(m,"A")// bind the primary class.def("foo",&Publicist::foo);// expose protected methods via the publicist

This works because&Publicist::foo is exactly the same function as&A::foo (same signature and address), just with a different accessmodifier. The only purpose of thePublicist helper class is to makethe function namepublic.

If the intent is to exposeprotectedvirtual functions which can beoverridden in Python, the publicist pattern can be combined with the previouslydescribed trampoline:

classA{public:virtual~A()=default;protected:virtualintfoo()const{return42;}};classTrampoline:publicA,py::trampoline_self_life_support{public:intfoo()constoverride{PYBIND11_OVERRIDE(int,A,foo,);}};classPublicist:publicA{public:usingA::foo;};py::class_<A,Trampoline,py::smart_holder>(m,"A")// <-- `Trampoline` here.def("foo",&Publicist::foo);// <-- `Publicist` here, not `Trampoline`!

Binding final classes#

Some classes may not be appropriate to inherit from. In C++11, classes canuse thefinal specifier to ensure that a class cannot be inherited from.Thepy::is_final attribute can be used to ensure that Python classescannot inherit from a specified type. The underlying C++ type does not needto be declared final.

classIsFinalfinal{};py::class_<IsFinal>(m,"IsFinal",py::is_final());

When you try to inherit from such a class in Python, you will now get thiserror:

>>>classPyFinalChild(IsFinal):...pass...TypeError: type 'IsFinal' is not an acceptable base type

Note

This attribute is currently ignored on PyPy

New in version 2.6.

Binding classes with template parameters#

pybind11 can also wrap classes that have template parameters. Consider these classes:

structCat{};structDog{};template<typenamePetType>structCage{Cage(PetType&pet);PetType&get();};

C++ templates may only be instantiated at compile time, so pybind11 can onlywrap instantiated templated classes. You cannot wrap a non-instantiated template:

// BROKEN (this will not compile)py::class_<Cage>(m,"Cage");.def("get",&Cage::get);

You must explicitly specify each template/type combination that you want towrap separately.

// okpy::class_<Cage<Cat>>(m,"CatCage").def("get",&Cage<Cat>::get);// okpy::class_<Cage<Dog>>(m,"DogCage").def("get",&Cage<Dog>::get);

If your class methods have template parameters you can wrap those as well,but once again each instantiation must be explicitly specified:

typename<typenameT>structMyClass{template<typenameV>Tfn(Vv);};py::class_<MyClass<int>>(m,"MyClassT").def("fn",&MyClass<int>::fn<std::string>);

Custom automatic downcasters#

As explained inInheritance and automatic downcasting, pybind11 comes with built-inunderstanding of the dynamic type of polymorphic objects in C++; thatis, returning a Pet to Python produces a Python object that knows it’swrapping a Dog, if Pet has virtual methods and pybind11 knows aboutDog and this Pet is in fact a Dog. Sometimes, you might want toprovide this automatic downcasting behavior when creating bindings fora class hierarchy that does not use standard C++ polymorphism, such asLLVM[3]. As long as there’s some way to determine at runtimewhether a downcast is safe, you can proceed by specializing thepybind11::polymorphic_type_hook template:

enumclassPetKind{Cat,Dog,Zebra};structPet{// Not polymorphic: has no virtual methodsconstPetKindkind;intage=0;protected:Pet(PetKind_kind):kind(_kind){}};structDog:Pet{Dog():Pet(PetKind::Dog){}std::stringsound="woof!";std::stringbark()const{returnsound;}};namespacePYBIND11_NAMESPACE{template<>structpolymorphic_type_hook<Pet>{staticconstvoid*get(constPet*src,conststd::type_info*&type){// note that src may be nullptrif(src&&src->kind==PetKind::Dog){type=&typeid(Dog);returnstatic_cast<constDog*>(src);}returnsrc;}};}// namespace PYBIND11_NAMESPACE

When pybind11 wants to convert a C++ pointer of typeBase* to aPython object, it callspolymorphic_type_hook<Base>::get() todetermine if a downcast is possible. Theget() function should usewhatever runtime information is available to determine if itssrcparameter is in fact an instance of some classDerived thatinherits fromBase. If it finds such aDerived, it setstype=&typeid(Derived) and returns a pointer to theDerived objectthat containssrc. Otherwise, it just returnssrc, leavingtype at its default value of nullptr. If you settype to atype that pybind11 doesn’t know about, no downcasting will occur, andthe originalsrc pointer will be used with its static typeBase*.

It is critical that the returned pointer andtype argument ofget() agree with each other: iftype is set to somethingnon-null, the returned pointer must point to the start of an objectwhose type istype. If the hierarchy being exposed uses onlysingle inheritance, a simplereturnsrc; will achieve this justfine, but in the general case, you must castsrc to theappropriate derived-class pointer (e.g. usingstatic_cast<Derived>(src)) before allowing it to be returned as avoid*.

[3]

https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html

Note

pybind11’s standard support for downcasting objects whose typeshave virtual methods is implemented usingpolymorphic_type_hook too, using the standard C++ ability todetermine the most-derived type of a polymorphic object usingtypeid() and to cast a base pointer to that most-derived type(even if you don’t know what it is) usingdynamic_cast<void*>.

See also

The filetests/test_tagbased_polymorphic.cpp contains amore complete example, including a demonstration of how to provideautomatic downcasting for an entire class hierarchy withoutwriting one get() function for each class.

Accessing the type object#

You can get the type object from a C++ class that has already been registered using:

py::typeT_py=py::type::of<T>();

You can directly usepy::type::of(ob) to get the type object from any pythonobject, just liketype(ob) in Python.

Note

Other types, likepy::type::of<int>(), do not work, seeType conversions.

New in version 2.6.

Custom type setup#

For advanced use cases, such as enabling garbage collection support, you maywish to directly manipulate thePyHeapTypeObject corresponding to apy::class_ definition.

You can do that usingpy::custom_type_setup:

structOwnsPythonObjects{py::objectvalue=py::none();};py::class_<OwnsPythonObjects>cls(m,"OwnsPythonObjects",py::custom_type_setup([](PyHeapTypeObject*heap_type){auto*type=&heap_type->ht_type;type->tp_flags|=Py_TPFLAGS_HAVE_GC;type->tp_traverse=[](PyObject*self_base,visitprocvisit,void*arg){// https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_traverse#if PY_VERSION_HEX >= 0x03090000Py_VISIT(Py_TYPE(self_base));#endifif(py::detail::is_holder_constructed(self_base)){auto&self=py::cast<OwnsPythonObjects&>(py::handle(self_base));Py_VISIT(self.value.ptr());}return0;};type->tp_clear=[](PyObject*self_base){if(py::detail::is_holder_constructed(self_base)){auto&self=py::cast<OwnsPythonObjects&>(py::handle(self_base));self.value=py::none();}return0;};}));cls.def(py::init<>());cls.def_readwrite("value",&OwnsPythonObjects::value);

New in version 2.8.

On this page

[8]ページ先頭

©2009-2025 Movatter.jp