|
|
.. _embedding: |
|
|
|
|
|
Embedding the interpreter |
|
|
######################### |
|
|
|
|
|
While pybind11 is mainly focused on extending Python using C++, it's also |
|
|
possible to do the reverse: embed the Python interpreter into a C++ program. |
|
|
All of the other documentation pages still apply here, so refer to them for |
|
|
general pybind11 usage. This section will cover a few extra things required |
|
|
for embedding. |
|
|
|
|
|
Getting started |
|
|
=============== |
|
|
|
|
|
A basic executable with an embedded interpreter can be created with just a few |
|
|
lines of CMake and the ``pybind11::embed`` target, as shown below. For more |
|
|
information, see :doc:`/compiling`. |
|
|
|
|
|
.. code-block:: cmake |
|
|
|
|
|
cmake_minimum_required(VERSION 3.5...3.27) |
|
|
project(example) |
|
|
|
|
|
find_package(pybind11 REQUIRED) # or `add_subdirectory(pybind11)` |
|
|
|
|
|
add_executable(example main.cpp) |
|
|
target_link_libraries(example PRIVATE pybind11::embed) |
|
|
|
|
|
The essential structure of the ``main.cpp`` file looks like this: |
|
|
|
|
|
.. code-block:: cpp |
|
|
|
|
|
#include <pybind11/embed.h> |
|
|
namespace py = pybind11; |
|
|
|
|
|
int main() { |
|
|
py::scoped_interpreter guard{}; |
|
|
|
|
|
py::print("Hello, World!"); |
|
|
} |
|
|
|
|
|
The interpreter must be initialized before using any Python API, which includes |
|
|
all the functions and classes in pybind11. The RAII guard class ``scoped_interpreter`` |
|
|
takes care of the interpreter lifetime. After the guard is destroyed, the interpreter |
|
|
shuts down and clears its memory. No Python functions can be called after this. |
|
|
|
|
|
Executing Python code |
|
|
===================== |
|
|
|
|
|
There are a few different ways to run Python code. One option is to use ``eval``, |
|
|
``exec`` or ``eval_file``, as explained in :ref:`eval`. Here is a quick example in |
|
|
the context of an executable with an embedded interpreter: |
|
|
|
|
|
.. code-block:: cpp |
|
|
|
|
|
#include <pybind11/embed.h> |
|
|
namespace py = pybind11; |
|
|
|
|
|
int main() { |
|
|
py::scoped_interpreter guard{}; |
|
|
|
|
|
py::exec(R"( |
|
|
kwargs = dict(name="World", number=42) |
|
|
message = "Hello, {name}! The answer is {number}".format(**kwargs) |
|
|
print(message) |
|
|
)"); |
|
|
} |
|
|
|
|
|
Alternatively, similar results can be achieved using pybind11's API (see |
|
|
:doc:`/advanced/pycpp/index` for more details). |
|
|
|
|
|
.. code-block:: cpp |
|
|
|
|
|
#include <pybind11/embed.h> |
|
|
namespace py = pybind11; |
|
|
using namespace py::literals; |
|
|
|
|
|
int main() { |
|
|
py::scoped_interpreter guard{}; |
|
|
|
|
|
auto kwargs = py::dict("name"_a="World", "number"_a=42); |
|
|
auto message = "Hello, {name}! The answer is {number}"_s.format(**kwargs); |
|
|
py::print(message); |
|
|
} |
|
|
|
|
|
The two approaches can also be combined: |
|
|
|
|
|
.. code-block:: cpp |
|
|
|
|
|
#include <pybind11/embed.h> |
|
|
#include <iostream> |
|
|
|
|
|
namespace py = pybind11; |
|
|
using namespace py::literals; |
|
|
|
|
|
int main() { |
|
|
py::scoped_interpreter guard{}; |
|
|
|
|
|
auto locals = py::dict("name"_a="World", "number"_a=42); |
|
|
py::exec(R"( |
|
|
message = "Hello, {name}! The answer is {number}".format(**locals()) |
|
|
)", py::globals(), locals); |
|
|
|
|
|
auto message = locals["message"].cast<std::string>(); |
|
|
std::cout << message; |
|
|
} |
|
|
|
|
|
Importing modules |
|
|
================= |
|
|
|
|
|
Python modules can be imported using ``module_::import()``: |
|
|
|
|
|
.. code-block:: cpp |
|
|
|
|
|
py::module_ sys = py::module_::import("sys"); |
|
|
py::print(sys.attr("path")); |
|
|
|
|
|
For convenience, the current working directory is included in ``sys.path`` when |
|
|
embedding the interpreter. This makes it easy to import local Python files: |
|
|
|
|
|
.. code-block:: python |
|
|
|
|
|
"""calc.py located in the working directory""" |
|
|
|
|
|
|
|
|
def add(i, j): |
|
|
return i + j |
|
|
|
|
|
|
|
|
.. code-block:: cpp |
|
|
|
|
|
py::module_ calc = py::module_::import("calc"); |
|
|
py::object result = calc.attr("add")(1, 2); |
|
|
int n = result.cast<int>(); |
|
|
assert(n == 3); |
|
|
|
|
|
Modules can be reloaded using ``module_::reload()`` if the source is modified e.g. |
|
|
by an external process. This can be useful in scenarios where the application |
|
|
imports a user defined data processing script which needs to be updated after |
|
|
changes by the user. Note that this function does not reload modules recursively. |
|
|
|
|
|
.. _embedding_modules: |
|
|
|
|
|
Adding embedded modules |
|
|
======================= |
|
|
|
|
|
Embedded binary modules can be added using the ``PYBIND11_EMBEDDED_MODULE`` macro. |
|
|
Note that the definition must be placed at global scope. They can be imported |
|
|
like any other module. |
|
|
|
|
|
.. code-block:: cpp |
|
|
|
|
|
#include <pybind11/embed.h> |
|
|
namespace py = pybind11; |
|
|
|
|
|
PYBIND11_EMBEDDED_MODULE(fast_calc, m) { |
|
|
|
|
|
m.def("add", [](int i, int j) { |
|
|
return i + j; |
|
|
}); |
|
|
} |
|
|
|
|
|
int main() { |
|
|
py::scoped_interpreter guard{}; |
|
|
|
|
|
auto fast_calc = py::module_::import("fast_calc"); |
|
|
auto result = fast_calc.attr("add")(1, 2).cast<int>(); |
|
|
assert(result == 3); |
|
|
} |
|
|
|
|
|
Unlike extension modules where only a single binary module can be created, on |
|
|
the embedded side an unlimited number of modules can be added using multiple |
|
|
``PYBIND11_EMBEDDED_MODULE`` definitions (as long as they have unique names). |
|
|
|
|
|
These modules are added to Python's list of builtins, so they can also be |
|
|
imported in pure Python files loaded by the interpreter. Everything interacts |
|
|
naturally: |
|
|
|
|
|
.. code-block:: python |
|
|
|
|
|
"""py_module.py located in the working directory""" |
|
|
import cpp_module |
|
|
|
|
|
a = cpp_module.a |
|
|
b = a + 1 |
|
|
|
|
|
|
|
|
.. code-block:: cpp |
|
|
|
|
|
#include <pybind11/embed.h> |
|
|
namespace py = pybind11; |
|
|
|
|
|
PYBIND11_EMBEDDED_MODULE(cpp_module, m) { |
|
|
m.attr("a") = 1; |
|
|
} |
|
|
|
|
|
int main() { |
|
|
py::scoped_interpreter guard{}; |
|
|
|
|
|
auto py_module = py::module_::import("py_module"); |
|
|
|
|
|
auto locals = py::dict("fmt"_a="{} + {} = {}", **py_module.attr("__dict__")); |
|
|
assert(locals["a"].cast<int>() == 1); |
|
|
assert(locals["b"].cast<int>() == 2); |
|
|
|
|
|
py::exec(R"( |
|
|
c = a + b |
|
|
message = fmt.format(a, b, c) |
|
|
)", py::globals(), locals); |
|
|
|
|
|
assert(locals["c"].cast<int>() == 3); |
|
|
assert(locals["message"].cast<std::string>() == "1 + 2 = 3"); |
|
|
} |
|
|
|
|
|
|
|
|
Interpreter lifetime |
|
|
==================== |
|
|
|
|
|
The Python interpreter shuts down when ``scoped_interpreter`` is destroyed. After |
|
|
this, creating a new instance will restart the interpreter. Alternatively, the |
|
|
``initialize_interpreter`` / ``finalize_interpreter`` pair of functions can be used |
|
|
to directly set the state at any time. |
|
|
|
|
|
Modules created with pybind11 can be safely re-initialized after the interpreter |
|
|
has been restarted. However, this may not apply to third-party extension modules. |
|
|
The issue is that Python itself cannot completely unload extension modules and |
|
|
there are several caveats with regard to interpreter restarting. In short, not |
|
|
all memory may be freed, either due to Python reference cycles or user-created |
|
|
global data. All the details can be found in the CPython documentation. |
|
|
|
|
|
.. warning:: |
|
|
|
|
|
Creating two concurrent ``scoped_interpreter`` guards is a fatal error. So is |
|
|
calling ``initialize_interpreter`` for a second time after the interpreter |
|
|
has already been initialized. |
|
|
|
|
|
Do not use the raw CPython API functions ``Py_Initialize`` and |
|
|
``Py_Finalize`` as these do not properly handle the lifetime of |
|
|
pybind11's internal data. |
|
|
|
|
|
|
|
|
Sub-interpreter support |
|
|
======================= |
|
|
|
|
|
Creating multiple copies of ``scoped_interpreter`` is not possible because it |
|
|
represents the main Python interpreter. Sub-interpreters are something different |
|
|
and they do permit the existence of multiple interpreters. This is an advanced |
|
|
feature of the CPython API and should be handled with care. pybind11 does not |
|
|
currently offer a C++ interface for sub-interpreters, so refer to the CPython |
|
|
documentation for all the details regarding this feature. |
|
|
|
|
|
We'll just mention a couple of caveats the sub-interpreters support in pybind11: |
|
|
|
|
|
1. Sub-interpreters will not receive independent copies of embedded modules. |
|
|
Instead, these are shared and modifications in one interpreter may be |
|
|
reflected in another. |
|
|
|
|
|
2. Managing multiple threads, multiple interpreters and the GIL can be |
|
|
challenging and there are several caveats here, even within the pure |
|
|
CPython API (please refer to the Python docs for details). As for |
|
|
pybind11, keep in mind that ``gil_scoped_release`` and ``gil_scoped_acquire`` |
|
|
do not take sub-interpreters into account. |
|
|
|