advanced.rst 68.8 KB
Newer Older
1
2
3
4
5
.. _advanced:

Advanced topics
###############

Wenzel Jakob's avatar
Wenzel Jakob committed
6
7
8
9
10
For brevity, the rest of this chapter assumes that the following two lines are
present:

.. code-block:: cpp

11
    #include <pybind11/pybind11.h>
Wenzel Jakob's avatar
Wenzel Jakob committed
12

13
    namespace py = pybind11;
Wenzel Jakob's avatar
Wenzel Jakob committed
14

15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Exporting constants and mutable objects
=======================================

To expose a C++ constant, use the ``attr`` function to register it in a module
as shown below. The ``int_`` class is one of many small wrapper objects defined
in ``pybind11/pytypes.h``. General objects (including integers) can also be
converted using the function ``cast``.

.. code-block:: cpp

    PYBIND11_PLUGIN(example) {
        py::module m("example", "pybind11 example plugin");
        m.attr("MY_CONSTANT") = py::int_(123);
        m.attr("MY_CONSTANT_2") = py::cast(new MyObject());
    }

31
32
33
Operator overloading
====================

Wenzel Jakob's avatar
Wenzel Jakob committed
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
Suppose that we're given the following ``Vector2`` class with a vector addition
and scalar multiplication operation, all implemented using overloaded operators
in C++.

.. code-block:: cpp

    class Vector2 {
    public:
        Vector2(float x, float y) : x(x), y(y) { }

        Vector2 operator+(const Vector2 &v) const { return Vector2(x + v.x, y + v.y); }
        Vector2 operator*(float value) const { return Vector2(x * value, y * value); }
        Vector2& operator+=(const Vector2 &v) { x += v.x; y += v.y; return *this; }
        Vector2& operator*=(float v) { x *= v; y *= v; return *this; }

Wenzel Jakob's avatar
Wenzel Jakob committed
49
50
51
        friend Vector2 operator*(float f, const Vector2 &v) {
            return Vector2(f * v.x, f * v.y);
        }
Wenzel Jakob's avatar
Wenzel Jakob committed
52

Wenzel Jakob's avatar
Wenzel Jakob committed
53
54
55
        std::string toString() const {
            return "[" + std::to_string(x) + ", " + std::to_string(y) + "]";
        }
Wenzel Jakob's avatar
Wenzel Jakob committed
56
57
58
59
60
61
62
63
64
    private:
        float x, y;
    };

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

.. code-block:: cpp

65
    #include <pybind11/operators.h>
Wenzel Jakob's avatar
Wenzel Jakob committed
66

67
    PYBIND11_PLUGIN(example) {
68
        py::module m("example", "pybind11 example plugin");
Wenzel Jakob's avatar
Wenzel Jakob committed
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100

        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("__repr__", &Vector2::toString);

        return m.ptr();
    }

Note that a line like

.. code-block:: cpp

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

is really just short hand notation for

.. code-block:: cpp

    .def("__mul__", [](const Vector2 &a, float b) {
        return a * b;
    })

This can be useful for exposing additional operators that don't exist on the
C++ side, or to perform other types of customization.

.. note::

    To use the more convenient ``py::self`` notation, the additional
101
    header file :file:`pybind11/operators.h` must be included.
Wenzel Jakob's avatar
Wenzel Jakob committed
102
103
104

.. seealso::

105
106
107
    The file :file:`example/example-operator-overloading.cpp` contains a
    complete example that demonstrates how to work with overloaded operators in
    more detail.
Wenzel Jakob's avatar
Wenzel Jakob committed
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142

Callbacks and passing anonymous functions
=========================================

The C++11 standard brought lambda functions and the generic polymorphic
function wrapper ``std::function<>`` to the C++ programming language, which
enable powerful new ways of working with functions. Lambda functions come in
two flavors: stateless lambda function resemble classic function pointers that
link to an anonymous piece of code, while stateful lambda functions
additionally depend on captured variables that are stored in an anonymous
*lambda closure object*.

Here is a simple example of a C++ function that takes an arbitrary function
(stateful or stateless) with signature ``int -> int`` as an argument and runs
it with the value 10.

.. code-block:: cpp

    int func_arg(const std::function<int(int)> &f) {
        return f(10);
    }

The example below is more involved: it takes a function of signature ``int -> int``
and returns another function of the same kind. The return value is a stateful
lambda function, which stores the value ``f`` in the capture object and adds 1 to
its return value upon execution.

.. code-block:: cpp

    std::function<int(int)> func_ret(const std::function<int(int)> &f) {
        return [f](int i) {
            return f(i) + 1;
        };
    }

143
144
145
146
147
148
149
150
151
152
153
This example demonstrates using python named parameters in C++ callbacks which
requires using ``py::cpp_function`` as a wrapper. Usage is similar to defining
methods of classes:

.. code-block:: cpp

    py::cpp_function func_cpp() {
        return py::cpp_function([](int i) { return i+1; },
           py::arg("number"));
    }

154
After including the extra header file :file:`pybind11/functional.h`, it is almost
155
trivial to generate binding code for all of these functions.
Wenzel Jakob's avatar
Wenzel Jakob committed
156
157
158

.. code-block:: cpp

159
    #include <pybind11/functional.h>
Wenzel Jakob's avatar
Wenzel Jakob committed
160

161
    PYBIND11_PLUGIN(example) {
162
        py::module m("example", "pybind11 example plugin");
Wenzel Jakob's avatar
Wenzel Jakob committed
163
164
165

        m.def("func_arg", &func_arg);
        m.def("func_ret", &func_ret);
166
        m.def("func_cpp", &func_cpp);
Wenzel Jakob's avatar
Wenzel Jakob committed
167
168
169
170
171
172

        return m.ptr();
    }

The following interactive session shows how to call them from Python.

173
.. code-block:: pycon
Wenzel Jakob's avatar
Wenzel Jakob committed
174
175
176
177
178
179
180
181
182
183
184

    $ python
    >>> import example
    >>> def square(i):
    ...     return i * i
    ...
    >>> example.func_arg(square)
    100L
    >>> square_plus_1 = example.func_ret(square)
    >>> square_plus_1(4)
    17L
185
186
187
    >>> plus_1 = func_cpp()
    >>> plus_1(number=43)
    44L
Wenzel Jakob's avatar
Wenzel Jakob committed
188

189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
.. warning::

    Keep in mind that passing a function from C++ to Python (or vice versa)
    will instantiate a piece of wrapper code that translates function
    invocations between the two languages. Naturally, this translation
    increases the computational cost of each function call somewhat. A
    problematic situation can arise when a function is copied back and forth
    between Python and C++ many times in a row, in which case the underlying
    wrappers will accumulate correspondingly. The resulting long sequence of
    C++ -> Python -> C++ -> ... roundtrips can significantly decrease
    performance.

    There is one exception: pybind11 detects case where a stateless function
    (i.e. a function pointer or a lambda function without captured variables)
    is passed as an argument to another C++ function exposed in Python. In this
    case, there is no overhead. Pybind11 will extract the underlying C++
    function pointer from the wrapped function to sidestep a potential C++ ->
    Python -> C++ roundtrip. This is demonstrated in Example 5.

Wenzel Jakob's avatar
Wenzel Jakob committed
208
209
210
.. note::

    This functionality is very useful when generating bindings for callbacks in
211
    C++ libraries (e.g. GUI libraries, asynchronous networking libraries, etc.).
Wenzel Jakob's avatar
Wenzel Jakob committed
212

213
214
215
    The file :file:`example/example-callbacks.cpp` contains a complete example
    that demonstrates how to work with callbacks and anonymous functions in
    more detail.
Wenzel Jakob's avatar
Wenzel Jakob committed
216

217
218
219
Overriding virtual functions in Python
======================================

Wenzel Jakob's avatar
Wenzel Jakob committed
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
Suppose that a C++ class or interface has a virtual function that we'd like to
to override from within Python (we'll focus on the class ``Animal``; ``Dog`` is
given as a specific example of how one would do this with traditional C++
code).

.. code-block:: cpp

    class Animal {
    public:
        virtual ~Animal() { }
        virtual std::string go(int n_times) = 0;
    };

    class Dog : public Animal {
    public:
235
        std::string go(int n_times) override {
Wenzel Jakob's avatar
Wenzel Jakob committed
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
            std::string result;
            for (int i=0; i<n_times; ++i)
                result += "woof! ";
            return result;
        }
    };

Let's also suppose that we are given a plain function which calls the
function ``go()`` on an arbitrary ``Animal`` instance.

.. code-block:: cpp

    std::string call_go(Animal *animal) {
        return animal->go(3);
    }

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

.. code-block:: cpp

256
    PYBIND11_PLUGIN(example) {
257
        py::module m("example", "pybind11 example plugin");
Wenzel Jakob's avatar
Wenzel Jakob committed
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285

        py::class_<Animal> animal(m, "Animal");
        animal
            .def("go", &Animal::go);

        py::class_<Dog>(m, "Dog", animal)
            .def(py::init<>());

        m.def("call_go", &call_go);

        return m.ptr();
    }

However, these bindings are impossible to extend: ``Animal`` is not
constructible, and we clearly require some kind of "trampoline" that
redirects virtual calls back to Python.

Defining a new type of ``Animal`` from within Python is possible but requires a
helper class that is defined as follows:

.. code-block:: cpp

    class PyAnimal : public Animal {
    public:
        /* Inherit the constructors */
        using Animal::Animal;

        /* Trampoline (need one for each virtual function) */
286
        std::string go(int n_times) override {
287
            PYBIND11_OVERLOAD_PURE(
Wenzel Jakob's avatar
Wenzel Jakob committed
288
289
290
291
292
293
294
295
                std::string, /* Return type */
                Animal,      /* Parent class */
                go,          /* Name of function */
                n_times      /* Argument(s) */
            );
        }
    };

296
297
The macro :func:`PYBIND11_OVERLOAD_PURE` should be used for pure virtual
functions, and :func:`PYBIND11_OVERLOAD` should be used for functions which have
298
a default implementation.
299
300
301
302
303
304
305

There are also two alternate macros :func:`PYBIND11_OVERLOAD_PURE_NAME` and
:func:`PYBIND11_OVERLOAD_NAME` which take a string-valued name argument
after the *Name of the function* slot. This is useful when the C++ and Python
versions of the function have different names, e.g. ``operator()`` vs ``__call__``.

The binding code also needs a few minor adaptations (highlighted):
Wenzel Jakob's avatar
Wenzel Jakob committed
306
307
308
309

.. code-block:: cpp
    :emphasize-lines: 4,6,7

310
    PYBIND11_PLUGIN(example) {
311
        py::module m("example", "pybind11 example plugin");
Wenzel Jakob's avatar
Wenzel Jakob committed
312

313
        py::class_<Animal, std::unique_ptr<Animal>, PyAnimal /* <--- trampoline*/> animal(m, "Animal");
Wenzel Jakob's avatar
Wenzel Jakob committed
314
315
316
317
318
319
320
321
322
323
324
325
        animal
            .def(py::init<>())
            .def("go", &Animal::go);

        py::class_<Dog>(m, "Dog", animal)
            .def(py::init<>());

        m.def("call_go", &call_go);

        return m.ptr();
    }

326
327
328
329
Importantly, pybind11 is made aware of the trampoline trampoline helper class
by specifying it as the *third* template argument to :class:`class_`. The
second argument with the unique pointer is simply the default holder type used
by pybind11. Following this, we are able to define a constructor as usual.
Wenzel Jakob's avatar
Wenzel Jakob committed
330

331
332
333
334
335
Note, however, that the above is sufficient for allowing python classes to
extend ``Animal``, but not ``Dog``: see ref:`virtual_and_inheritance` for the
necessary steps required to providing proper overload support for inherited
classes.

Wenzel Jakob's avatar
Wenzel Jakob committed
336
337
338
The Python session below shows how to override ``Animal::go`` and invoke it via
a virtual method call.

339
.. code-block:: pycon
Wenzel Jakob's avatar
Wenzel Jakob committed
340
341
342
343
344
345
346
347
348
349
350
351
352

    >>> from example import *
    >>> d = Dog()
    >>> call_go(d)
    u'woof! woof! woof! '
    >>> class Cat(Animal):
    ...     def go(self, n_times):
    ...             return "meow! " * n_times
    ...
    >>> c = Cat()
    >>> call_go(c)
    u'meow! meow! meow! '

353
Please take a look at the :ref:`macro_notes` before using this feature.
354

Wenzel Jakob's avatar
Wenzel Jakob committed
355
356
.. seealso::

357
358
359
    The file :file:`example/example-virtual-functions.cpp` contains a complete
    example that demonstrates how to override virtual functions using pybind11
    in more detail.
Wenzel Jakob's avatar
Wenzel Jakob committed
360

361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
.. _virtual_and_inheritance:

Combining virtual functions and inheritance
===========================================

When combining virtual methods with inheritance, you need to be sure to provide
an override for each method for which you want to allow overrides from derived
python classes.  For example, suppose we extend the above ``Animal``/``Dog``
example as follows:

.. code-block:: cpp
    class Animal {
    public:
        virtual std::string go(int n_times) = 0;
        virtual std::string name() { return "unknown"; }
    };
    class Dog : public class Animal {
    public:
        std::string go(int n_times) override {
            std::string result;
            for (int i=0; i<n_times; ++i)
                result += bark() + " ";
            return result;
        }
        virtual std::string bark() { return "woof!"; }
    };

then the trampoline class for ``Animal`` must, as described in the previous
section, override ``go()`` and ``name()``, but in order to allow python code to
inherit properly from ``Dog``, we also need a trampoline class for ``Dog`` that
overrides both the added ``bark()`` method *and* the ``go()`` and ``name()``
methods inherited from ``Animal`` (even though ``Dog`` doesn't directly
override the ``name()`` method):

.. code-block:: cpp
    class PyAnimal : public Animal {
    public:
        using Animal::Animal; // Inherit constructors
        std::string go(int n_times) override { PYBIND11_OVERLOAD_PURE(std::string, Animal, go, n_times); }
        std::string name() override { PYBIND11_OVERLOAD(std::string, Animal, name, ); }
    };
    class PyDog : public Dog {
    public:
        using Dog::Dog; // Inherit constructors
        std::string go(int n_times) override { PYBIND11_OVERLOAD_PURE(std::string, Dog, go, n_times); }
        std::string name() override { PYBIND11_OVERLOAD(std::string, Dog, name, ); }
        std::string bark() override { PYBIND11_OVERLOAD(std::string, Dog, bark, ); }
    };

A registered class derived from a pybind11-registered class with virtual
methods requires a similar trampoline class, *even if* it doesn't explicitly
declare or override any virtual methods itself:

.. code-block:: cpp
    class Husky : public Dog {};
    class PyHusky : public Husky {
        using Dog::Dog; // Inherit constructors
        std::string go(int n_times) override { PYBIND11_OVERLOAD_PURE(std::string, Husky, go, n_times); }
        std::string name() override { PYBIND11_OVERLOAD(std::string, Husky, name, ); }
        std::string bark() override { PYBIND11_OVERLOAD(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 virtual
methods).  The technique involves using template trampoline classes, as
follows:

.. code-block:: cpp
    template <class AnimalBase = Animal> class PyAnimal : public AnimalBase {
        using AnimalBase::AnimalBase; // Inherit constructors
        std::string go(int n_times) override { PYBIND11_OVERLOAD_PURE(std::string, AnimalBase, go, n_times); }
        std::string name() override { PYBIND11_OVERLOAD(std::string, AnimalBase, name, ); }
    };
    template <class DogBase = Dog> class PyDog : public PyAnimal<DogBase> {
        using PyAnimal<DogBase>::PyAnimal; // Inherit constructors
        // Override PyAnimal's pure virtual go() with a non-pure one:
        std::string go(int n_times) override { PYBIND11_OVERLOAD(std::string, DogBase, go, n_times); }
        std::string bark() override { PYBIND11_OVERLOAD(std::string, DogBase, bark, ); }
    };

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

The classes are then registered with pybind11 using:

.. code-block:: cpp
    py::class_<Animal, std::unique_ptr<Animal>, PyAnimal<>> animal(m, "Animal");
    py::class_<Dog, std::unique_ptr<Dog>, PyDog<>> dog(m, "Dog");
    py::class_<Husky, std::unique_ptr<Husky>, PyDog<Husky>> husky(m, "Husky");
    // ... add animal, dog, husky definitions

Note that ``Husky`` did not require a dedicated trampoline template class at
all, since it neither declares any new virtual methods nor provides any pure
virtual method implementations.

With either the repeated-virtuals or templated trampoline methods in place, you
can now create a python class that inherits from ``Dog``:

.. code-block:: python

    class ShihTzu(Dog):
        def bark(self):
            return "yip!"

.. seealso::

    See the file :file:`example-virtual-functions.cpp` for complete examples
    using both the duplication and templated trampoline approaches.

473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
.. _macro_notes:

General notes regarding convenience macros
==========================================

pybind11 provides a few convenience macros such as
:func:`PYBIND11_MAKE_OPAQUE` and :func:`PYBIND11_DECLARE_HOLDER_TYPE`, and
``PYBIND11_OVERLOAD_*``. Since these are "just" macros that are evaluated
in the preprocessor (which has no concept of types), they *will* get confused
by commas in a template argument such as ``PYBIND11_OVERLOAD(MyReturnValue<T1,
T2>, myFunc)``. In this case, the preprocessor assumes that the comma indicates
the beginnning of the next parameter. Use a ``typedef`` to bind the template to
another name and use it in the macro to avoid this problem.


Wenzel Jakob's avatar
Wenzel Jakob committed
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
Global Interpreter Lock (GIL)
=============================

The classes :class:`gil_scoped_release` and :class:`gil_scoped_acquire` can be
used to acquire and release the global interpreter lock in the body of a C++
function call. In this way, long-running C++ code can be parallelized using
multiple Python threads. Taking the previous section as an example, this could
be realized as follows (important changes highlighted):

.. code-block:: cpp
    :emphasize-lines: 8,9,33,34

    class PyAnimal : public Animal {
    public:
        /* Inherit the constructors */
        using Animal::Animal;

        /* Trampoline (need one for each virtual function) */
        std::string go(int n_times) {
            /* Acquire GIL before calling Python code */
508
            py::gil_scoped_acquire acquire;
Wenzel Jakob's avatar
Wenzel Jakob committed
509
510
511
512
513
514
515
516
517
518
519
520
521

            PYBIND11_OVERLOAD_PURE(
                std::string, /* Return type */
                Animal,      /* Parent class */
                go,          /* Name of function */
                n_times      /* Argument(s) */
            );
        }
    };

    PYBIND11_PLUGIN(example) {
        py::module m("example", "pybind11 example plugin");

522
        py::class_<Animal, std::unique_ptr<Animal>, PyAnimal> animal(m, "Animal");
Wenzel Jakob's avatar
Wenzel Jakob committed
523
524
525
526
527
528
529
530
531
        animal
            .def(py::init<>())
            .def("go", &Animal::go);

        py::class_<Dog>(m, "Dog", animal)
            .def(py::init<>());

        m.def("call_go", [](Animal *animal) -> std::string {
            /* Release GIL before calling into (potentially long-running) C++ code */
532
            py::gil_scoped_release release;
Wenzel Jakob's avatar
Wenzel Jakob committed
533
534
535
536
537
538
            return call_go(animal);
        });

        return m.ptr();
    }

Wenzel Jakob's avatar
Wenzel Jakob committed
539
Passing STL data structures
540
541
===========================

542
When including the additional header file :file:`pybind11/stl.h`, conversions
Wenzel Jakob's avatar
Wenzel Jakob committed
543
544
545
546
between ``std::vector<>``, ``std::list<>``, ``std::set<>``, and ``std::map<>``
and the Python ``list``, ``set`` and ``dict`` data structures are automatically
enabled. The types ``std::pair<>`` and ``std::tuple<>`` are already supported
out of the box with just the core :file:`pybind11/pybind11.h` header.
Wenzel Jakob's avatar
Wenzel Jakob committed
547
548
549

.. note::

550
    Arbitrary nesting of any of these types is supported.
Wenzel Jakob's avatar
Wenzel Jakob committed
551
552
553

.. seealso::

554
555
    The file :file:`example/example-python-types.cpp` contains a complete
    example that demonstrates how to pass STL data types in more detail.
Wenzel Jakob's avatar
Wenzel Jakob committed
556

557
558
Binding sequence data types, iterators, the slicing protocol, etc.
==================================================================
Wenzel Jakob's avatar
Wenzel Jakob committed
559
560
561
562
563

Please refer to the supplemental example for details.

.. seealso::

564
565
566
567
    The file :file:`example/example-sequences-and-iterators.cpp` contains a
    complete example that shows how to bind a sequence data type, including
    length queries (``__len__``), iterators (``__iter__``), the slicing
    protocol and other kinds of useful operations.
Wenzel Jakob's avatar
Wenzel Jakob committed
568

569
570
571
Return value policies
=====================

Wenzel Jakob's avatar
Wenzel Jakob committed
572
573
574
575
576
577
578
Python and C++ use wildly different ways of managing the memory and lifetime of
objects managed by them. This can lead to issues when creating bindings for
functions that return a non-trivial type. Just by looking at the type
information, it is not clear whether Python should take charge of the returned
value and eventually free its resources, or if this is handled on the C++ side.
For this reason, pybind11 provides a several `return value policy` annotations
that can be passed to the :func:`module::def` and :func:`class_::def`
579
functions. The default policy is :enum:`return_value_policy::automatic`.
Wenzel Jakob's avatar
Wenzel Jakob committed
580

Wenzel Jakob's avatar
Wenzel Jakob committed
581
582
.. tabularcolumns:: |p{0.5\textwidth}|p{0.45\textwidth}|

Wenzel Jakob's avatar
Wenzel Jakob committed
583
584
585
586
587
+--------------------------------------------------+----------------------------------------------------------------------------+
| Return value policy                              | Description                                                                |
+==================================================+============================================================================+
| :enum:`return_value_policy::automatic`           | This is the default return value policy, which falls back to the policy    |
|                                                  | :enum:`return_value_policy::take_ownership` when the return value is a     |
Wenzel Jakob's avatar
Wenzel Jakob committed
588
589
|                                                  | pointer. Otherwise, it uses :enum:`return_value::move` or                  |
|                                                  | :enum:`return_value::copy` for rvalue and lvalue references, respectively. |
Wenzel Jakob's avatar
Wenzel Jakob committed
590
591
592
|                                                  | See below for a description of what all of these different policies do.    |
+--------------------------------------------------+----------------------------------------------------------------------------+
| :enum:`return_value_policy::automatic_reference` | As above, but use policy :enum:`return_value_policy::reference` when the   |
593
594
595
|                                                  | return value is a pointer. This is the default conversion policy for       |
|                                                  | function arguments when calling Python functions manually from C++ code    |
|                                                  | (i.e. via handle::operator()). You probably won't need to use this.        |
Wenzel Jakob's avatar
Wenzel Jakob committed
596
597
598
599
+--------------------------------------------------+----------------------------------------------------------------------------+
| :enum:`return_value_policy::take_ownership`      | Reference an existing object (i.e. do not create a new copy) and take      |
|                                                  | ownership. Python will call the destructor and delete operator when the    |
|                                                  | object's reference count reaches zero. Undefined behavior ensues when the  |
Wenzel Jakob's avatar
Wenzel Jakob committed
600
|                                                  | C++ side does the same.                                                    |
Wenzel Jakob's avatar
Wenzel Jakob committed
601
602
603
604
605
606
607
608
609
610
611
612
+--------------------------------------------------+----------------------------------------------------------------------------+
| :enum:`return_value_policy::copy`                | Create a new copy of the returned object, which will be owned by Python.   |
|                                                  | This policy is comparably safe because the lifetimes of the two instances  |
|                                                  | are decoupled.                                                             |
+--------------------------------------------------+----------------------------------------------------------------------------+
| :enum:`return_value_policy::move`                | Use ``std::move`` to move the return value contents into a new instance    |
|                                                  | that will be owned by Python. This policy is comparably safe because the   |
|                                                  | lifetimes of the two instances (move source and destination) are decoupled.|
+--------------------------------------------------+----------------------------------------------------------------------------+
| :enum:`return_value_policy::reference`           | Reference an existing object, but do not take ownership. The C++ side is   |
|                                                  | responsible for managing the object's lifetime and deallocating it when    |
|                                                  | it is no longer used. Warning: undefined behavior will ensue when the C++  |
Wenzel Jakob's avatar
Wenzel Jakob committed
613
|                                                  | side deletes an object that is still referenced and used by Python.        |
Wenzel Jakob's avatar
Wenzel Jakob committed
614
+--------------------------------------------------+----------------------------------------------------------------------------+
615
616
617
618
619
| :enum:`return_value_policy::reference_internal`  | Like :enum:`return_value_policy::reference` but additionally applies a     |
|                                                  | :class:`keep_alive<0,1>()` call policy (described next) that keeps the     |
|                                                  | ``this`` argument of the function or property from being garbage collected |
|                                                  | as long as the return value remains referenced.  See the                   |
|                                                  | :class:`keep_alive` call policy (described next) for details.              |
Wenzel Jakob's avatar
Wenzel Jakob committed
620
+--------------------------------------------------+----------------------------------------------------------------------------+
Wenzel Jakob's avatar
Wenzel Jakob committed
621

622
623
.. warning::

624
625
    Code with invalid return value policies might access unitialized memory or
    free data structures multiple times, which can lead to hard-to-debug
626
627
628
    non-determinism and segmentation faults, hence it is worth spending the
    time to understand all the different options in the table above.

629
630
631
632
One important aspect of the above policies is that they only apply to instances
which pybind11 has *not* seen before, in which case the policy clarifies
essential questions about the return value's lifetime and ownership.  When
pybind11 knows the instance already (as identified by its type and address in
633
memory), it will return the existing Python object wrapper rather than creating
634
a copy.
635

Wenzel Jakob's avatar
Wenzel Jakob committed
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
.. note::

    The next section on :ref:`call_policies` discusses *call policies* that can be
    specified *in addition* to a return value policy from the list above. Call
    policies indicate reference relationships that can involve both return values
    and parameters of functions.

.. note::

   As an alternative to elaborate call policies and lifetime management logic,
   consider using smart pointers (see the section on :ref:`smart_pointers` for
   details). Smart pointers can tell whether an object is still referenced from
   C++ or Python, which generally eliminates the kinds of inconsistencies that
   can lead to crashes or undefined behavior. For functions returning smart
   pointers, it is not necessary to specify a return value policy.
651

Wenzel Jakob's avatar
Wenzel Jakob committed
652
653
.. _call_policies:

654
655
656
657
658
659
660
661
Additional call policies
========================

In addition to the above return value policies, further `call policies` can be
specified to indicate dependencies between parameters. There is currently just
one policy named ``keep_alive<Nurse, Patient>``, which indicates that the
argument with index ``Patient`` should be kept alive at least until the
argument with index ``Nurse`` is freed by the garbage collector; argument
662
663
664
indices start at one, while zero refers to the return value. For methods, index
one refers to the implicit ``this`` pointer, while regular arguments begin at
index two. Arbitrarily many call policies can be specified.
665

666
667
668
Consider the following example: the binding code for a list append operation
that ties the lifetime of the newly added element to the underlying container
might be declared as follows:
669
670
671
672
673
674
675
676
677
678
679
680

.. code-block:: cpp

    py::class_<List>(m, "List")
        .def("append", &List::append, py::keep_alive<1, 2>());

.. note::

    ``keep_alive`` is analogous to the ``with_custodian_and_ward`` (if Nurse,
    Patient != 0) and ``with_custodian_and_ward_postcall`` (if Nurse/Patient ==
    0) policies from Boost.Python.

681
682
.. seealso::

683
684
    The file :file:`example/example-keep-alive.cpp` contains a complete example
    that demonstrates using :class:`keep_alive` in more detail.
685

Wenzel Jakob's avatar
Wenzel Jakob committed
686
687
688
689
Implicit type conversions
=========================

Suppose that instances of two types ``A`` and ``B`` are used in a project, and
690
that an ``A`` can easily be converted into an instance of type ``B`` (examples of this
Wenzel Jakob's avatar
Wenzel Jakob committed
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
could be a fixed and an arbitrary precision number type).

.. code-block:: cpp

    py::class_<A>(m, "A")
        /// ... members ...

    py::class_<B>(m, "B")
        .def(py::init<A>())
        /// ... members ...

    m.def("func",
        [](const B &) { /* .... */ }
    );

To invoke the function ``func`` using a variable ``a`` containing an ``A``
instance, we'd have to write ``func(B(a))`` in Python. On the other hand, C++
will automatically apply an implicit type conversion, which makes it possible
to directly write ``func(a)``.
710

Wenzel Jakob's avatar
Wenzel Jakob committed
711
712
713
714
715
716
717
718
In this situation (i.e. where ``B`` has a constructor that converts from
``A``), the following statement enables similar implicit conversions on the
Python side:

.. code-block:: cpp

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

719
720
721
722
723
.. note::

    Implicit conversions from ``A`` to ``B`` only work when ``B`` is a custom
    data type that is exposed to Python via pybind11.

724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
.. _static_properties:

Static properties
=================

The section on :ref:`properties` discussed the creation of instance properties
that are implemented in terms of C++ getters and setters.

Static properties can also be created in a similar way to expose getters and
setters of static class attributes. It is important to note that the implicit
``self`` argument also exists in this case and is used to pass the Python
``type`` subclass instance. This parameter will often not be needed by the C++
side, and the following example illustrates how to instantiate a lambda getter
function that ignores it:

.. code-block:: cpp

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

744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
Unique pointers
===============

Given a class ``Example`` with Python bindings, it's possible to return
instances wrapped in C++11 unique pointers, like so

.. code-block:: cpp

    std::unique_ptr<Example> create_example() { return std::unique_ptr<Example>(new Example()); }

.. code-block:: cpp

    m.def("create_example", &create_example);

In other words, there is nothing special that needs to be done. While returning
unique pointers in this way is allowed, it is *illegal* to use them as function
arguments. For instance, the following function signature cannot be processed
by pybind11.

.. code-block:: cpp

    void do_something_with_example(std::unique_ptr<Example> ex) { ... }

The above signature would imply that Python needs to give up ownership of an
object that is passed to this function, which is generally not possible (for
instance, the object might be referenced elsewhere).

Wenzel Jakob's avatar
Wenzel Jakob committed
771
772
.. _smart_pointers:

Wenzel Jakob's avatar
Wenzel Jakob committed
773
774
775
Smart pointers
==============

776
This section explains how to pass values that are wrapped in "smart" pointer
Wenzel Jakob's avatar
Wenzel Jakob committed
777
778
types with internal reference counting. For the simpler C++11 unique pointers,
refer to the previous section.
779

Wenzel Jakob's avatar
Wenzel Jakob committed
780
The binding generator for classes, :class:`class_`, takes an optional second
Wenzel Jakob's avatar
Wenzel Jakob committed
781
782
783
784
785
template type, which denotes a special *holder* type that is used to manage
references to the object. When wrapping a type named ``Type``, the default
value of this template parameter is ``std::unique_ptr<Type>``, which means that
the object is deallocated when Python's reference count goes to zero.

786
787
788
It is possible to switch to other types of reference counting wrappers or smart
pointers, which is useful in codebases that rely on them. For instance, the
following snippet causes ``std::shared_ptr`` to be used instead.
Wenzel Jakob's avatar
Wenzel Jakob committed
789
790
791

.. code-block:: cpp

792
    py::class_<Example, std::shared_ptr<Example> /* <- holder type */> obj(m, "Example");
Wenzel Jakob's avatar
Wenzel Jakob committed
793

794
Note that any particular class can only be associated with a single holder type.
Wenzel Jakob's avatar
Wenzel Jakob committed
795

796
To enable transparent conversions for functions that take shared pointers as an
Wenzel Jakob's avatar
Wenzel Jakob committed
797
argument or that return them, a macro invocation similar to the following must
798
799
800
801
be declared at the top level before any binding code:

.. code-block:: cpp

802
    PYBIND11_DECLARE_HOLDER_TYPE(T, std::shared_ptr<T>);
803

804
.. note::
805
806
807
808
809
810
811

    The first argument of :func:`PYBIND11_DECLARE_HOLDER_TYPE` should be a
    placeholder name that is used as a template parameter of the second
    argument. Thus, feel free to use any identifier, but use it consistently on
    both sides; also, don't use the name of a type that already exists in your
    codebase.

812
813
814
815
816
817
818
One potential stumbling block when using holder types is that they need to be
applied consistently. Can you guess what's broken about the following binding
code?

.. code-block:: cpp

    class Child { };
819

820
821
822
823
824
825
826
    class Parent {
    public:
       Parent() : child(std::make_shared<Child>()) { }
       Child *get_child() { return child.get(); }  /* Hint: ** DON'T DO THIS ** */
    private:
        std::shared_ptr<Child> child;
    };
827

828
829
    PYBIND11_PLUGIN(example) {
        py::module m("example");
Wenzel Jakob's avatar
Wenzel Jakob committed
830

831
        py::class_<Child, std::shared_ptr<Child>>(m, "Child");
Wenzel Jakob's avatar
Wenzel Jakob committed
832

833
834
835
836
837
838
        py::class_<Parent, std::shared_ptr<Parent>>(m, "Parent")
           .def(py::init<>())
           .def("get_child", &Parent::get_child);

        return m.ptr();
    }
Wenzel Jakob's avatar
Wenzel Jakob committed
839

840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
The following Python code will cause undefined behavior (and likely a
segmentation fault).

.. code-block:: python

   from example import Parent
   print(Parent().get_child())

The problem is that ``Parent::get_child()`` returns a pointer to an instance of
``Child``, but the fact that this instance is already managed by
``std::shared_ptr<...>`` is lost when passing raw pointers. In this case,
pybind11 will create a second independent ``std::shared_ptr<...>`` that also
claims ownership of the pointer. In the end, the object will be freed **twice**
since these shared pointers have no way of knowing about each other.

There are two ways to resolve this issue:

1. For types that are managed by a smart pointer class, never use raw pointers
   in function arguments or return values. In other words: always consistently
   wrap pointers into their designated holder types (such as
   ``std::shared_ptr<...>``). In this case, the signature of ``get_child()``
   should be modified as follows:

.. code-block:: cpp

    std::shared_ptr<Child> get_child() { return child; }

2. Adjust the definition of ``Child`` by specifying
   ``std::enable_shared_from_this<T>`` (see cppreference_ for details) as a
   base class. This adds a small bit of information to ``Child`` that allows
   pybind11 to realize that there is already an existing
   ``std::shared_ptr<...>`` and communicate with it. In this case, the
   declaration of ``Child`` should look as follows:
Wenzel Jakob's avatar
Wenzel Jakob committed
873

874
875
.. _cppreference: http://en.cppreference.com/w/cpp/memory/enable_shared_from_this

876
877
878
879
.. code-block:: cpp

    class Child : public std::enable_shared_from_this<Child> { };

880
881
882

Please take a look at the :ref:`macro_notes` before using this feature.

Wenzel Jakob's avatar
Wenzel Jakob committed
883
884
.. seealso::

885
886
887
    The file :file:`example/example-smart-ptr.cpp` contains a complete example
    that demonstrates how to work with custom reference-counting holder types
    in more detail.
Wenzel Jakob's avatar
Wenzel Jakob committed
888

Wenzel Jakob's avatar
Wenzel Jakob committed
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
.. _custom_constructors:

Custom constructors
===================

The syntax for binding constructors was previously introduced, but it only
works when a constructor with the given parameters actually exists on the C++
side. To extend this to more general cases, let's take a look at what actually
happens under the hood: the following statement

.. code-block:: cpp

    py::class_<Example>(m, "Example")
        .def(py::init<int>());

is short hand notation for

.. code-block:: cpp

    py::class_<Example>(m, "Example")
        .def("__init__",
            [](Example &instance, int arg) {
                new (&instance) Example(arg);
            }
        );

In other words, :func:`init` creates an anonymous function that invokes an
in-place constructor. Memory allocation etc. is already take care of beforehand
within pybind11.

919
920
.. _catching_and_throwing_exceptions:

Wenzel Jakob's avatar
Wenzel Jakob committed
921
922
923
924
925
926
927
928
Catching and throwing exceptions
================================

When C++ code invoked from Python throws an ``std::exception``, it is
automatically converted into a Python ``Exception``. pybind11 defines multiple
special exception classes that will map to different types of Python
exceptions:

Wenzel Jakob's avatar
Wenzel Jakob committed
929
930
.. tabularcolumns:: |p{0.5\textwidth}|p{0.45\textwidth}|

Wenzel Jakob's avatar
Wenzel Jakob committed
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
+--------------------------------------+------------------------------+
|  C++ exception type                  |  Python exception type       |
+======================================+==============================+
| :class:`std::exception`              | ``RuntimeError``             |
+--------------------------------------+------------------------------+
| :class:`std::bad_alloc`              | ``MemoryError``              |
+--------------------------------------+------------------------------+
| :class:`std::domain_error`           | ``ValueError``               |
+--------------------------------------+------------------------------+
| :class:`std::invalid_argument`       | ``ValueError``               |
+--------------------------------------+------------------------------+
| :class:`std::length_error`           | ``ValueError``               |
+--------------------------------------+------------------------------+
| :class:`std::out_of_range`           | ``ValueError``               |
+--------------------------------------+------------------------------+
| :class:`std::range_error`            | ``ValueError``               |
+--------------------------------------+------------------------------+
| :class:`pybind11::stop_iteration`    | ``StopIteration`` (used to   |
|                                      | implement custom iterators)  |
+--------------------------------------+------------------------------+
| :class:`pybind11::index_error`       | ``IndexError`` (used to      |
|                                      | indicate out of bounds       |
|                                      | accesses in ``__getitem__``, |
|                                      | ``__setitem__``, etc.)       |
+--------------------------------------+------------------------------+
956
957
958
959
| :class:`pybind11::value_error`       | ``ValueError`` (used to      |
|                                      | indicate wrong value passed  |
|                                      | in ``container.remove(...)`` |
+--------------------------------------+------------------------------+
960
961
962
963
964
965
| :class:`pybind11::key_error`         | ``KeyError`` (used to        |
|                                      | indicate out of bounds       |
|                                      | accesses in ``__getitem__``, |
|                                      | ``__setitem__`` in dict-like |
|                                      | objects, etc.)               |
+--------------------------------------+------------------------------+
Wenzel Jakob's avatar
Wenzel Jakob committed
966
967
968
969
| :class:`pybind11::error_already_set` | Indicates that the Python    |
|                                      | exception flag has already   |
|                                      | been initialized             |
+--------------------------------------+------------------------------+
Wenzel Jakob's avatar
Wenzel Jakob committed
970
971
972
973
974
975
976
977

When a Python function invoked from C++ throws an exception, it is converted
into a C++ exception of type :class:`error_already_set` whose string payload
contains a textual summary.

There is also a special exception :class:`cast_error` that is thrown by
:func:`handle::call` when the input arguments cannot be converted to Python
objects.
978

979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
Registering custom exception translators
========================================

If the default exception conversion policy described
:ref:`above <catching_and_throwing_exceptions>`
is insufficient, pybind11 also provides support for registering custom
exception translators.

The function ``register_exception_translator(translator)`` takes a stateless
callable (e.g. a function pointer or a lambda function without captured
variables) with the following call signature: ``void(std::exception_ptr)``.

When a C++ exception is thrown, registered exception translators are tried
in reverse order of registration (i.e. the last registered translator gets
a first shot at handling the exception).

Inside the translator, ``std::rethrow_exception`` should be used within
a try block to re-throw the exception. A catch clause can then use
``PyErr_SetString`` to set a Python exception as demonstrated
998
in :file:`example-custom-exceptions.cpp``.
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037

This example also demonstrates how to create custom exception types
with ``py::exception``.

The following example demonstrates this for a hypothetical exception class
``MyCustomException``:

.. code-block:: cpp

    py::register_exception_translator([](std::exception_ptr p) {
        try {
            if (p) std::rethrow_exception(p);
        } catch (const MyCustomException &e) {
            PyErr_SetString(PyExc_RuntimeError, e.what());
        }
    });

Multiple exceptions can be handled by a single translator. If the exception is
not caught by the current translator, the previously registered one gets a
chance.

If none of the registered exception translators is able to handle the
exception, it is handled by the default converter as described in the previous
section.

.. note::

    You must either call ``PyErr_SetString`` for every exception caught in a
    custom exception translator. Failure to do so will cause Python to crash
    with ``SystemError: error return without exception set``.

    Exceptions that you do not plan to handle should simply not be caught.

    You may also choose to explicity (re-)throw the exception to delegate it to
    the other existing exception translators.

    The ``py::exception`` wrapper for creating custom exceptions cannot (yet)
    be used as a ``py::base``.

1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
.. _opaque:

Treating STL data structures as opaque objects
==============================================

pybind11 heavily relies on a template matching mechanism to convert parameters
and return values that are constructed from STL data types such as vectors,
linked lists, hash tables, etc. This even works in a recursive manner, for
instance to deal with lists of hash maps of pairs of elementary and custom
types, etc.

However, a fundamental limitation of this approach is that internal conversions
between Python and C++ types involve a copy operation that prevents
pass-by-reference semantics. What does this mean?

Suppose we bind the following function

.. code-block:: cpp

    void append_1(std::vector<int> &v) {
       v.push_back(1);
    }

and call it from Python, the following happens:

1063
.. code-block:: pycon
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091

   >>> v = [5, 6]
   >>> append_1(v)
   >>> print(v)
   [5, 6]

As you can see, when passing STL data structures by reference, modifications
are not propagated back the Python side. A similar situation arises when
exposing STL data structures using the ``def_readwrite`` or ``def_readonly``
functions:

.. code-block:: cpp

    /* ... definition ... */

    class MyClass {
        std::vector<int> contents;
    };

    /* ... binding code ... */

    py::class_<MyClass>(m, "MyClass")
        .def(py::init<>)
        .def_readwrite("contents", &MyClass::contents);

In this case, properties can be read and written in their entirety. However, an
``append`` operaton involving such a list type has no effect:

1092
.. code-block:: pycon
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131

   >>> m = MyClass()
   >>> m.contents = [5, 6]
   >>> print(m.contents)
   [5, 6]
   >>> m.contents.append(7)
   >>> print(m.contents)
   [5, 6]

To deal with both of the above situations, pybind11 provides a macro named
``PYBIND11_MAKE_OPAQUE(T)`` that disables the template-based conversion
machinery of types, thus rendering them *opaque*. The contents of opaque
objects are never inspected or extracted, hence they can be passed by
reference. For instance, to turn ``std::vector<int>`` into an opaque type, add
the declaration

.. code-block:: cpp

    PYBIND11_MAKE_OPAQUE(std::vector<int>);

before any binding code (e.g. invocations to ``class_::def()``, etc.). This
macro must be specified at the top level, since instantiates a partial template
overload. If your binding code consists of multiple compilation units, it must
be present in every file preceding any usage of ``std::vector<int>``. Opaque
types must also have a corresponding ``class_`` declaration to associate them
with a name in Python, and to define a set of available operations:

.. code-block:: cpp

    py::class_<std::vector<int>>(m, "IntVector")
        .def(py::init<>())
        .def("clear", &std::vector<int>::clear)
        .def("pop_back", &std::vector<int>::pop_back)
        .def("__len__", [](const std::vector<int> &v) { return v.size(); })
        .def("__iter__", [](std::vector<int> &v) {
           return py::make_iterator(v.begin(), v.end());
        }, py::keep_alive<0, 1>()) /* Keep vector alive while iterator is used */
        // ....

1132
Please take a look at the :ref:`macro_notes` before using this feature.
1133
1134
1135

.. seealso::

1136
1137
1138
    The file :file:`example/example-opaque-types.cpp` contains a complete
    example that demonstrates how to create and expose opaque types using
    pybind11 in more detail.
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149

.. _eigen:

Transparent conversion of dense and sparse Eigen data types
===========================================================

Eigen [#f1]_ is C++ header-based library for dense and sparse linear algebra. Due to
its popularity and widespread adoption, pybind11 provides transparent
conversion support between Eigen and Scientific Python linear algebra data types.

Specifically, when including the optional header file :file:`pybind11/eigen.h`,
1150
pybind11 will automatically and transparently convert
1151
1152
1153
1154

1. Static and dynamic Eigen dense vectors and matrices to instances of
   ``numpy.ndarray`` (and vice versa).

1155
2. Returned matrix expressions such as blocks (including columns or rows) and
1156
1157
1158
   diagonals will be converted to ``numpy.ndarray`` of the expression
   values.

1159
3. Returned matrix-like objects such as Eigen::DiagonalMatrix or
1160
1161
1162
   Eigen::SelfAdjointView will be converted to ``numpy.ndarray`` containing the
   expressed value.

1163
4. Eigen sparse vectors and matrices to instances of
1164
1165
1166
1167
1168
1169
1170
1171
   ``scipy.sparse.csr_matrix``/``scipy.sparse.csc_matrix`` (and vice versa).

This makes it possible to bind most kinds of functions that rely on these types.
One major caveat are functions that take Eigen matrices *by reference* and modify
them somehow, in which case the information won't be propagated to the caller.

.. code-block:: cpp

1172
1173
    /* The Python bindings of these functions won't replicate
       the intended effect of modifying the function arguments */
1174
    void scale_by_2(Eigen::Vector3f &v) {
1175
1176
1177
1178
        v *= 2;
    }
    void scale_by_2(Eigen::Ref<Eigen::MatrixXd> &v) {
        v *= 2;
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
    }

To see why this is, refer to the section on :ref:`opaque` (although that
section specifically covers STL data types, the underlying issue is the same).
The next two sections discuss an efficient alternative for exposing the
underlying native Eigen types as opaque objects in a way that still integrates
with NumPy and SciPy.

.. [#f1] http://eigen.tuxfamily.org

.. seealso::

    The file :file:`example/eigen.cpp` contains a complete example that
    shows how to pass Eigen sparse and dense data types in more detail.

1194
1195
1196
1197
Buffer protocol
===============

Python supports an extremely general and convenient approach for exchanging
1198
1199
1200
data between plugin libraries. Types can expose a buffer view [#f2]_, which
provides fast direct access to the raw internal data representation. Suppose we
want to bind the following simplistic Matrix class:
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217

.. code-block:: cpp

    class Matrix {
    public:
        Matrix(size_t rows, size_t cols) : m_rows(rows), m_cols(cols) {
            m_data = new float[rows*cols];
        }
        float *data() { return m_data; }
        size_t rows() const { return m_rows; }
        size_t cols() const { return m_cols; }
    private:
        size_t m_rows, m_cols;
        float *m_data;
    };

The following binding code exposes the ``Matrix`` contents as a buffer object,
1218
making it possible to cast Matrices into NumPy arrays. It is even possible to
1219
1220
1221
1222
1223
1224
1225
1226
completely avoid copy operations with Python expressions like
``np.array(matrix_instance, copy = False)``.

.. code-block:: cpp

    py::class_<Matrix>(m, "Matrix")
       .def_buffer([](Matrix &m) -> py::buffer_info {
            return py::buffer_info(
1227
1228
1229
1230
1231
1232
                m.data(),                            /* Pointer to buffer */
                sizeof(float),                       /* Size of one scalar */
                py::format_descriptor<float>::value, /* Python struct-style format descriptor */
                2,                                   /* Number of dimensions */
                { m.rows(), m.cols() },              /* Buffer dimensions */
                { sizeof(float) * m.rows(),          /* Strides (in bytes) for each index */
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
                  sizeof(float) }
            );
        });

The snippet above binds a lambda function, which can create ``py::buffer_info``
description records on demand describing a given matrix. The contents of
``py::buffer_info`` mirror the Python buffer protocol specification.

.. code-block:: cpp

    struct buffer_info {
        void *ptr;
        size_t itemsize;
        std::string format;
        int ndim;
        std::vector<size_t> shape;
        std::vector<size_t> strides;
    };

To create a C++ function that can take a Python buffer object as an argument,
simply use the type ``py::buffer`` as one of its arguments. Buffers can exist
in a great variety of configurations, hence some safety checks are usually
necessary in the function body. Below, you can see an basic example on how to
define a custom constructor for the Eigen double precision matrix
(``Eigen::MatrixXd``) type, which supports initialization from compatible
1258
buffer objects (e.g. a NumPy matrix).
1259
1260
1261

.. code-block:: cpp

1262
1263
1264
1265
1266
1267
1268
1269
    /* Bind MatrixXd (or some other Eigen type) to Python */
    typedef Eigen::MatrixXd Matrix;

    typedef Matrix::Scalar Scalar;
    constexpr bool rowMajor = Matrix::Flags & Eigen::RowMajorBit;

    py::class_<Matrix>(m, "Matrix")
        .def("__init__", [](Matrix &m, py::buffer b) {
1270
1271
            typedef Eigen::Stride<Eigen::Dynamic, Eigen::Dynamic> Strides;

1272
1273
1274
1275
            /* Request a buffer descriptor from Python */
            py::buffer_info info = b.request();

            /* Some sanity checks ... */
1276
            if (info.format != py::format_descriptor<Scalar>::value)
1277
1278
1279
1280
1281
                throw std::runtime_error("Incompatible format: expected a double array!");

            if (info.ndim != 2)
                throw std::runtime_error("Incompatible buffer dimension!");

1282
            auto strides = Strides(
1283
1284
                info.strides[rowMajor ? 0 : 1] / sizeof(Scalar),
                info.strides[rowMajor ? 1 : 0] / sizeof(Scalar));
1285
1286

            auto map = Eigen::Map<Matrix, 0, Strides>(
1287
                static_cat<Scalar *>(info.ptr), info.shape[0], info.shape[1], strides);
1288
1289

            new (&m) Matrix(map);
1290
1291
        });

1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
For reference, the ``def_buffer()`` call for this Eigen data type should look
as follows:

.. code-block:: cpp

    .def_buffer([](Matrix &m) -> py::buffer_info {
        return py::buffer_info(
            m.data(),                /* Pointer to buffer */
            sizeof(Scalar),          /* Size of one scalar */
            /* Python struct-style format descriptor */
            py::format_descriptor<Scalar>::value,
            /* Number of dimensions */
            2,
            /* Buffer dimensions */
            { (size_t) m.rows(),
              (size_t) m.cols() },
            /* Strides (in bytes) for each index */
            { sizeof(Scalar) * (rowMajor ? m.cols() : 1),
              sizeof(Scalar) * (rowMajor ? 1 : m.rows()) }
        );
     })

For a much easier approach of binding Eigen types (although with some
limitations), refer to the section on :ref:`eigen`.

Wenzel Jakob's avatar
Wenzel Jakob committed
1317
1318
.. seealso::

1319
1320
    The file :file:`example/example-buffers.cpp` contains a complete example
    that demonstrates using the buffer protocol with pybind11 in more detail.
Wenzel Jakob's avatar
Wenzel Jakob committed
1321

1322
.. [#f2] http://docs.python.org/3/c-api/buffer.html
Wenzel Jakob's avatar
Wenzel Jakob committed
1323

1324
1325
1326
1327
1328
NumPy support
=============

By exchanging ``py::buffer`` with ``py::array`` in the above snippet, we can
restrict the function so that it only accepts NumPy arrays (rather than any
Wenzel Jakob's avatar
Wenzel Jakob committed
1329
type of Python object satisfying the buffer protocol).
1330
1331

In many situations, we want to define a function which only accepts a NumPy
Wenzel Jakob's avatar
Wenzel Jakob committed
1332
array of a certain data type. This is possible via the ``py::array_t<T>``
1333
template. For instance, the following function requires the argument to be a
1334
NumPy array containing double precision values.
1335
1336
1337

.. code-block:: cpp

Wenzel Jakob's avatar
Wenzel Jakob committed
1338
    void f(py::array_t<double> array);
1339

1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
When it is invoked with a different type (e.g. an integer or a list of
integers), the binding code will attempt to cast the input into a NumPy array
of the requested type. Note that this feature requires the
:file:``pybind11/numpy.h`` header to be included.

Data in NumPy arrays is not guaranteed to packed in a dense manner;
furthermore, entries can be separated by arbitrary column and row strides.
Sometimes, it can be useful to require a function to only accept dense arrays
using either the C (row-major) or Fortran (column-major) ordering. This can be
accomplished via a second template argument with values ``py::array::c_style``
or ``py::array::f_style``.

.. code-block:: cpp

1354
    void f(py::array_t<double, py::array::c_style | py::array::forcecast> array);
1355

1356
1357
1358
1359
The ``py::array::forcecast`` argument is the default value of the second
template paramenter, and it ensures that non-conforming arguments are converted
into an array satisfying the specified requirements instead of trying the next
function overload.
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371

Vectorizing functions
=====================

Suppose we want to bind a function with the following signature to Python so
that it can process arbitrary NumPy array arguments (vectors, matrices, general
N-D arrays) in addition to its normal arguments:

.. code-block:: cpp

    double my_func(int x, float y, double z);

1372
After including the ``pybind11/numpy.h`` header, this is extremely simple:
1373
1374
1375
1376
1377
1378

.. code-block:: cpp

    m.def("vectorized_func", py::vectorize(my_func));

Invoking the function like below causes 4 calls to be made to ``my_func`` with
1379
each of the array elements. The significant advantage of this compared to
Wenzel Jakob's avatar
Wenzel Jakob committed
1380
1381
1382
solutions like ``numpy.vectorize()`` is that the loop over the elements runs
entirely on the C++ side and can be crunched down into a tight, optimized loop
by the compiler. The result is returned as a NumPy array of type
1383
1384
``numpy.dtype.float64``.

1385
.. code-block:: pycon
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396

    >>> x = np.array([[1, 3],[5, 7]])
    >>> y = np.array([[2, 4],[6, 8]])
    >>> z = 3
    >>> result = vectorized_func(x, y, z)

The scalar argument ``z`` is transparently replicated 4 times.  The input
arrays ``x`` and ``y`` are automatically converted into the right types (they
are of type  ``numpy.dtype.int64`` but need to be ``numpy.dtype.int32`` and
``numpy.dtype.float32``, respectively)

1397
Sometimes we might want to explicitly exclude an argument from the vectorization
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
because it makes little sense to wrap it in a NumPy array. For instance,
suppose the function signature was

.. code-block:: cpp

    double my_func(int x, float y, my_custom_type *z);

This can be done with a stateful Lambda closure:

.. code-block:: cpp

    // Vectorize a lambda function with a capture object (e.g. to exclude some arguments from the vectorization)
    m.def("vectorized_func",
Wenzel Jakob's avatar
Wenzel Jakob committed
1411
        [](py::array_t<int> x, py::array_t<float> y, my_custom_type *z) {
1412
1413
1414
1415
1416
            auto stateful_closure = [z](int x, float y) { return my_func(x, y, z); };
            return py::vectorize(stateful_closure)(x, y);
        }
    );

1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
In cases where the computation is too complicated to be reduced to
``vectorize``, it will be necessary to create and access the buffer contents
manually. The following snippet contains a complete example that shows how this
works (the code is somewhat contrived, since it could have been done more
simply using ``vectorize``).

.. code-block:: cpp

    #include <pybind11/pybind11.h>
    #include <pybind11/numpy.h>

    namespace py = pybind11;

    py::array_t<double> add_arrays(py::array_t<double> input1, py::array_t<double> input2) {
        auto buf1 = input1.request(), buf2 = input2.request();

        if (buf1.ndim != 1 || buf2.ndim != 1)
            throw std::runtime_error("Number of dimensions must be one");

        if (buf1.shape[0] != buf2.shape[0])
            throw std::runtime_error("Input shapes must match");

        auto result = py::array(py::buffer_info(
            nullptr,            /* Pointer to data (nullptr -> ask NumPy to allocate!) */
            sizeof(double),     /* Size of one item */
Wenzel Jakob's avatar
Wenzel Jakob committed
1442
            py::format_descriptor<double>::value, /* Buffer format */
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
            buf1.ndim,          /* How many dimensions? */
            { buf1.shape[0] },  /* Number of elements for each dimension */
            { sizeof(double) }  /* Strides for each dimension */
        ));

        auto buf3 = result.request();

        double *ptr1 = (double *) buf1.ptr,
               *ptr2 = (double *) buf2.ptr,
               *ptr3 = (double *) buf3.ptr;

        for (size_t idx = 0; idx < buf1.shape[0]; idx++)
            ptr3[idx] = ptr1[idx] + ptr2[idx];

        return result;
    }

    PYBIND11_PLUGIN(test) {
        py::module m("test");
        m.def("add_arrays", &add_arrays, "Add two NumPy arrays");
        return m.ptr();
    }

Wenzel Jakob's avatar
Wenzel Jakob committed
1466
.. seealso::
1467

1468
1469
    The file :file:`example/example-numpy-vectorize.cpp` contains a complete
    example that demonstrates using :func:`vectorize` in more detail.
1470

Wenzel Jakob's avatar
Wenzel Jakob committed
1471
1472
Functions taking Python objects as arguments
============================================
1473

Wenzel Jakob's avatar
Wenzel Jakob committed
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
pybind11 exposes all major Python types using thin C++ wrapper classes. These
wrapper classes can also be used as parameters of functions in bindings, which
makes it possible to directly work with native Python types on the C++ side.
For instance, the following statement iterates over a Python ``dict``:

.. code-block:: cpp

    void print_dict(py::dict dict) {
        /* Easily interact with Python types */
        for (auto item : dict)
            std::cout << "key=" << item.first << ", "
                      << "value=" << item.second << std::endl;
    }

Available types include :class:`handle`, :class:`object`, :class:`bool_`,
1489
:class:`int_`, :class:`float_`, :class:`str`, :class:`bytes`, :class:`tuple`,
Wenzel Jakob's avatar
Wenzel Jakob committed
1490
1491
1492
:class:`list`, :class:`dict`, :class:`slice`, :class:`none`, :class:`capsule`,
:class:`iterable`, :class:`iterator`, :class:`function`, :class:`buffer`,
:class:`array`, and :class:`array_t`.
Wenzel Jakob's avatar
Wenzel Jakob committed
1493

1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
In this kind of mixed code, it is often necessary to convert arbitrary C++
types to Python, which can be done using :func:`cast`:

.. code-block:: cpp

    MyClass *cls = ..;
    py::object obj = py::cast(cls);

The reverse direction uses the following syntax:

.. code-block:: cpp

    py::object obj = ...;
    MyClass *cls = obj.cast<MyClass *>();

When conversion fails, both directions throw the exception :class:`cast_error`.
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
It is also possible to call python functions via ``operator()``.

.. code-block:: cpp

    py::function f = <...>;
    py::object result_py = f(1234, "hello", some_instance);
    MyClass &result = result_py.cast<MyClass>();

The special ``f(*args)`` and ``f(*args, **kwargs)`` syntax is also supported to
supply arbitrary argument and keyword lists, although these cannot be mixed
with other parameters.

.. code-block:: cpp

    py::function f = <...>;
    py::tuple args = py::make_tuple(1234);
    py::dict kwargs;
    kwargs["y"] = py::cast(5678);
    py::object result = f(*args, **kwargs);
1529

Wenzel Jakob's avatar
Wenzel Jakob committed
1530
1531
.. seealso::

1532
1533
1534
1535
    The file :file:`example/example-python-types.cpp` contains a complete
    example that demonstrates passing native Python types in more detail. The
    file :file:`example/example-arg-keywords-and-defaults.cpp` discusses usage
    of ``args`` and ``kwargs``.
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557

Default arguments revisited
===========================

The section on :ref:`default_args` previously discussed basic usage of default
arguments using pybind11. One noteworthy aspect of their implementation is that
default arguments are converted to Python objects right at declaration time.
Consider the following example:

.. code-block:: cpp

    py::class_<MyClass>("MyClass")
        .def("myFunction", py::arg("arg") = SomeType(123));

In this case, pybind11 must already be set up to deal with values of the type
``SomeType`` (via a prior instantiation of ``py::class_<SomeType>``), or an
exception will be thrown.

Another aspect worth highlighting is that the "preview" of the default argument
in the function signature is generated using the object's ``__repr__`` method.
If not available, the signature may not be very helpful, e.g.:

1558
.. code-block:: pycon
1559
1560
1561
1562

    FUNCTIONS
    ...
    |  myFunction(...)
Wenzel Jakob's avatar
Wenzel Jakob committed
1563
    |      Signature : (MyClass, arg : SomeType = <SomeType object at 0x101b7b080>) -> NoneType
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
    ...

The first way of addressing this is by defining ``SomeType.__repr__``.
Alternatively, it is possible to specify the human-readable preview of the
default argument manually using the ``arg_t`` notation:

.. code-block:: cpp

    py::class_<MyClass>("MyClass")
        .def("myFunction", py::arg_t<SomeType>("arg", SomeType(123), "SomeType(123)"));

Wenzel Jakob's avatar
Wenzel Jakob committed
1575
1576
1577
1578
1579
1580
1581
1582
1583
Sometimes it may be necessary to pass a null pointer value as a default
argument. In this case, remember to cast it to the underlying type in question,
like so:

.. code-block:: cpp

    py::class_<MyClass>("MyClass")
        .def("myFunction", py::arg("arg") = (SomeType *) nullptr);

1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
Binding functions that accept arbitrary numbers of arguments and keywords arguments
===================================================================================

Python provides a useful mechanism to define functions that accept arbitrary
numbers of arguments and keyword arguments:

.. code-block:: cpp

   def generic(*args, **kwargs):
       # .. do something with args and kwargs

Such functions can also be created using pybind11:

.. code-block:: cpp

   void generic(py::args args, py::kwargs kwargs) {
       /// .. do something with args
       if (kwargs)
           /// .. do something with kwargs
   }

   /// Binding code
   m.def("generic", &generic);

1608
1609
1610
1611
1612
(See ``example/example-arg-keywords-and-defaults.cpp``). The class ``py::args``
derives from ``py::list`` and ``py::kwargs`` derives from ``py::dict`` Note
that the ``kwargs`` argument is invalid if no keyword arguments were actually
provided.  Please refer to the other examples for details on how to iterate
over these, and on how to cast their entries into C++ objects.
1613

1614
1615
1616
1617
1618
.. warning::

   Unlike Python, pybind11 does not allow combining normal parameters with the
   ``args`` / ``kwargs`` special parameters.

1619
1620
1621
Partitioning code over multiple extension modules
=================================================

1622
1623
1624
1625
1626
It's straightforward to split binding code over multiple extension modules,
while referencing types that are declared elsewhere. Everything "just" works
without any special precautions. One exception to this rule occurs when
extending a type declared in another extension module. Recall the basic example
from Section :ref:`inheritance`.
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651

.. code-block:: cpp

    py::class_<Pet> pet(m, "Pet");
    pet.def(py::init<const std::string &>())
       .def_readwrite("name", &Pet::name);

    py::class_<Dog>(m, "Dog", pet /* <- specify parent */)
        .def(py::init<const std::string &>())
        .def("bark", &Dog::bark);

Suppose now that ``Pet`` bindings are defined in a module named ``basic``,
whereas the ``Dog`` bindings are defined somewhere else. The challenge is of
course that the variable ``pet`` is not available anymore though it is needed
to indicate the inheritance relationship to the constructor of ``class_<Dog>``.
However, it can be acquired as follows:

.. code-block:: cpp

    py::object pet = (py::object) py::module::import("basic").attr("Pet");

    py::class_<Dog>(m, "Dog", pet)
        .def(py::init<const std::string &>())
        .def("bark", &Dog::bark);

1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
Alternatively, we can rely on the ``base`` tag, which performs an automated
lookup of the corresponding Python type. However, this also requires invoking
the ``import`` function once to ensure that the pybind11 binding code of the
module ``basic`` has been executed.

.. code-block:: cpp

    py::module::import("basic");

    py::class_<Dog>(m, "Dog", py::base<Pet>())
        .def(py::init<const std::string &>())
        .def("bark", &Dog::bark);
Wenzel Jakob's avatar
Wenzel Jakob committed
1664

Wenzel Jakob's avatar
Wenzel Jakob committed
1665
1666
Naturally, both methods will fail when there are cyclic dependencies.

1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
Note that compiling code which has its default symbol visibility set to
*hidden* (e.g. via the command line flag ``-fvisibility=hidden`` on GCC/Clang) can interfere with the
ability to access types defined in another extension module. Workarounds
include changing the global symbol visibility (not recommended, because it will
lead unnecessarily large binaries) or manually exporting types that are
accessed by multiple extension modules:

.. code-block:: cpp

    #ifdef _WIN32
    #  define EXPORT_TYPE __declspec(dllexport)
    #else
    #  define EXPORT_TYPE __attribute__ ((visibility("default")))
    #endif

    class EXPORT_TYPE Dog : public Animal {
        ...
    };


Wenzel Jakob's avatar
Wenzel Jakob committed
1687
1688
1689
1690
1691
Pickling support
================

Python's ``pickle`` module provides a powerful facility to serialize and
de-serialize a Python object graph into a binary data stream. To pickle and
Wenzel Jakob's avatar
typos  
Wenzel Jakob committed
1692
unpickle C++ classes using pybind11, two additional functions must be provided.
Wenzel Jakob's avatar
Wenzel Jakob committed
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
Suppose the class in question has the following signature:

.. code-block:: cpp

    class Pickleable {
    public:
        Pickleable(const std::string &value) : m_value(value) { }
        const std::string &value() const { return m_value; }

        void setExtra(int extra) { m_extra = extra; }
        int extra() const { return m_extra; }
    private:
        std::string m_value;
        int m_extra = 0;
    };

1709
The binding code including the requisite ``__setstate__`` and ``__getstate__`` methods [#f3]_
Wenzel Jakob's avatar
Wenzel Jakob committed
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
looks as follows:

.. code-block:: cpp

    py::class_<Pickleable>(m, "Pickleable")
        .def(py::init<std::string>())
        .def("value", &Pickleable::value)
        .def("extra", &Pickleable::extra)
        .def("setExtra", &Pickleable::setExtra)
        .def("__getstate__", [](const Pickleable &p) {
            /* Return a tuple that fully encodes the state of the object */
            return py::make_tuple(p.value(), p.extra());
        })
        .def("__setstate__", [](Pickleable &p, py::tuple t) {
            if (t.size() != 2)
                throw std::runtime_error("Invalid state!");

Wenzel Jakob's avatar
Wenzel Jakob committed
1727
1728
            /* Invoke the in-place constructor. Note that this is needed even
               when the object just has a trivial default constructor */
Wenzel Jakob's avatar
Wenzel Jakob committed
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
            new (&p) Pickleable(t[0].cast<std::string>());

            /* Assign any additional state */
            p.setExtra(t[1].cast<int>());
        });

An instance can now be pickled as follows:

.. code-block:: python

    try:
        import cPickle as pickle  # Use cPickle on Python 2.7
    except ImportError:
        import pickle

    p = Pickleable("test_value")
    p.setExtra(15)
1746
1747
1748
1749
1750
1751
1752
1753
1754
    data = pickle.dumps(p, 2)

Note that only the cPickle module is supported on Python 2.7. The second
argument to ``dumps`` is also crucial: it selects the pickle protocol version
2, since the older version 1 is not supported. Newer versions are also fine—for
instance, specify ``-1`` to always use the latest available version. Beware:
failure to follow these instructions will cause important pybind11 memory
allocation routines to be skipped during unpickling, which will likely lead to
memory corruption and/or segmentation faults.
Wenzel Jakob's avatar
Wenzel Jakob committed
1755
1756
1757

.. seealso::

1758
1759
1760
    The file :file:`example/example-pickling.cpp` contains a complete example
    that demonstrates how to pickle and unpickle types using pybind11 in more
    detail.
Wenzel Jakob's avatar
Wenzel Jakob committed
1761

1762
.. [#f3] http://docs.python.org/3/library/pickle.html#pickling-class-instances
1763
1764
1765
1766

Generating documentation using Sphinx
=====================================

1767
Sphinx [#f4]_ has the ability to inspect the signatures and documentation
1768
strings in pybind11-based extension modules to automatically generate beautiful
Wenzel Jakob's avatar
Wenzel Jakob committed
1769
documentation in a variety formats. The python_example repository [#f5]_ contains a
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
simple example repository which uses this approach.

There are two potential gotchas when using this approach: first, make sure that
the resulting strings do not contain any :kbd:`TAB` characters, which break the
docstring parsing routines. You may want to use C++11 raw string literals,
which are convenient for multi-line comments. Conveniently, any excess
indentation will be automatically be removed by Sphinx. However, for this to
work, it is important that all lines are indented consistently, i.e.:

.. code-block:: cpp

    // ok
    m.def("foo", &foo, R"mydelimiter(
        The foo function

        Parameters
        ----------
    )mydelimiter");

    // *not ok*
    m.def("foo", &foo, R"mydelimiter(The foo function

        Parameters
        ----------
    )mydelimiter");

1796
.. [#f4] http://www.sphinx-doc.org
Wenzel Jakob's avatar
Wenzel Jakob committed
1797
.. [#f5] http://github.com/pybind/python_example
Klemens Morgenstern's avatar
Klemens Morgenstern committed
1798

1799
1800
Evaluating Python expressions from strings and files
====================================================
Klemens Morgenstern's avatar
Klemens Morgenstern committed
1801

1802
1803
1804
1805
1806
1807
1808
1809
1810
pybind11 provides the :func:`eval` and :func:`eval_file` functions to evaluate
Python expressions and statements. The following example illustrates how they
can be used.

Both functions accept a template parameter that describes how the argument
should be interpreted. Possible choices include ``eval_expr`` (isolated
expression), ``eval_single_statement`` (a single statement, return value is
always ``none``), and ``eval_statements`` (sequence of statements, return value
is always ``none``).
Klemens Morgenstern's avatar
Klemens Morgenstern committed
1811
1812
1813

.. code-block:: cpp

1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
    // At beginning of file
    #include <pybind11/eval.h>

    ...

    // Evaluate in scope of main module
    py::object scope = py::module::import("__main__").attr("__dict__");

    // Evaluate an isolated expression
    int result = py::eval("my_variable + 10", scope).cast<int>();
Klemens Morgenstern's avatar
Klemens Morgenstern committed
1824

1825
1826
1827
1828
1829
    // Evaluate a sequence of statements
    py::eval<py::eval_statements>(
        "print('Hello')\n"
        "print('world!');",
        scope);
Klemens Morgenstern's avatar
Klemens Morgenstern committed
1830

1831
1832
    // Evaluate the statements in an separate Python file on disk
    py::eval_file("script.py", scope);
Klemens Morgenstern's avatar
Klemens Morgenstern committed
1833