1.. highlightlang:: c
2
3
4.. _embedding:
5
6***************************************
7Embedding Python in Another Application
8***************************************
9
10The previous chapters discussed how to extend Python, that is, how to extend the
11functionality of Python by attaching a library of C functions to it.  It is also
12possible to do it the other way around: enrich your C/C++ application by
13embedding Python in it.  Embedding provides your application with the ability to
14implement some of the functionality of your application in Python rather than C
15or C++. This can be used for many purposes; one example would be to allow users
16to tailor the application to their needs by writing some scripts in Python.  You
17can also use it yourself if some of the functionality can be written in Python
18more easily.
19
20Embedding Python is similar to extending it, but not quite.  The difference is
21that when you extend Python, the main program of the application is still the
22Python interpreter, while if you embed Python, the main program may have nothing
23to do with Python --- instead, some parts of the application occasionally call
24the Python interpreter to run some Python code.
25
26So if you are embedding Python, you are providing your own main program.  One of
27the things this main program has to do is initialize the Python interpreter.  At
28the very least, you have to call the function :c:func:`Py_Initialize`.  There are
29optional calls to pass command line arguments to Python.  Then later you can
30call the interpreter from any part of the application.
31
32There are several different ways to call the interpreter: you can pass a string
33containing Python statements to :c:func:`PyRun_SimpleString`, or you can pass a
34stdio file pointer and a file name (for identification in error messages only)
35to :c:func:`PyRun_SimpleFile`.  You can also call the lower-level operations
36described in the previous chapters to construct and use Python objects.
37
38
39.. seealso::
40
41   :ref:`c-api-index`
42      The details of Python's C interface are given in this manual. A great deal of
43      necessary information can be found here.
44
45
46.. _high-level-embedding:
47
48Very High Level Embedding
49=========================
50
51The simplest form of embedding Python is the use of the very high level
52interface. This interface is intended to execute a Python script without needing
53to interact with the application directly. This can for example be used to
54perform some operation on a file. ::
55
56   #include <Python.h>
57
58   int
59   main(int argc, char *argv[])
60   {
61       wchar_t *program = Py_DecodeLocale(argv[0], NULL);
62       if (program == NULL) {
63           fprintf(stderr, "Fatal error: cannot decode argv[0]\n");
64           exit(1);
65       }
66       Py_SetProgramName(program);  /* optional but recommended */
67       Py_Initialize();
68       PyRun_SimpleString("from time import time,ctime\n"
69                          "print('Today is', ctime(time()))\n");
70       if (Py_FinalizeEx() < 0) {
71           exit(120);
72       }
73       PyMem_RawFree(program);
74       return 0;
75   }
76
77The :c:func:`Py_SetProgramName` function should be called before
78:c:func:`Py_Initialize` to inform the interpreter about paths to Python run-time
79libraries.  Next, the Python interpreter is initialized with
80:c:func:`Py_Initialize`, followed by the execution of a hard-coded Python script
81that prints the date and time.  Afterwards, the :c:func:`Py_FinalizeEx` call shuts
82the interpreter down, followed by the end of the program.  In a real program,
83you may want to get the Python script from another source, perhaps a text-editor
84routine, a file, or a database.  Getting the Python code from a file can better
85be done by using the :c:func:`PyRun_SimpleFile` function, which saves you the
86trouble of allocating memory space and loading the file contents.
87
88
89.. _lower-level-embedding:
90
91Beyond Very High Level Embedding: An overview
92=============================================
93
94The high level interface gives you the ability to execute arbitrary pieces of
95Python code from your application, but exchanging data values is quite
96cumbersome to say the least. If you want that, you should use lower level calls.
97At the cost of having to write more C code, you can achieve almost anything.
98
99It should be noted that extending Python and embedding Python is quite the same
100activity, despite the different intent. Most topics discussed in the previous
101chapters are still valid. To show this, consider what the extension code from
102Python to C really does:
103
104#. Convert data values from Python to C,
105
106#. Perform a function call to a C routine using the converted values, and
107
108#. Convert the data values from the call from C to Python.
109
110When embedding Python, the interface code does:
111
112#. Convert data values from C to Python,
113
114#. Perform a function call to a Python interface routine using the converted
115   values, and
116
117#. Convert the data values from the call from Python to C.
118
119As you can see, the data conversion steps are simply swapped to accommodate the
120different direction of the cross-language transfer. The only difference is the
121routine that you call between both data conversions. When extending, you call a
122C routine, when embedding, you call a Python routine.
123
124This chapter will not discuss how to convert data from Python to C and vice
125versa.  Also, proper use of references and dealing with errors is assumed to be
126understood.  Since these aspects do not differ from extending the interpreter,
127you can refer to earlier chapters for the required information.
128
129
130.. _pure-embedding:
131
132Pure Embedding
133==============
134
135The first program aims to execute a function in a Python script. Like in the
136section about the very high level interface, the Python interpreter does not
137directly interact with the application (but that will change in the next
138section).
139
140The code to run a function defined in a Python script is:
141
142.. literalinclude:: ../includes/run-func.c
143
144
145This code loads a Python script using ``argv[1]``, and calls the function named
146in ``argv[2]``.  Its integer arguments are the other values of the ``argv``
147array.  If you :ref:`compile and link <compiling>` this program (let's call
148the finished executable :program:`call`), and use it to execute a Python
149script, such as:
150
151.. code-block:: python
152
153   def multiply(a,b):
154       print("Will compute", a, "times", b)
155       c = 0
156       for i in range(0, a):
157           c = c + b
158       return c
159
160then the result should be:
161
162.. code-block:: shell-session
163
164   $ call multiply multiply 3 2
165   Will compute 3 times 2
166   Result of call: 6
167
168Although the program is quite large for its functionality, most of the code is
169for data conversion between Python and C, and for error reporting.  The
170interesting part with respect to embedding Python starts with ::
171
172   Py_Initialize();
173   pName = PyUnicode_DecodeFSDefault(argv[1]);
174   /* Error checking of pName left out */
175   pModule = PyImport_Import(pName);
176
177After initializing the interpreter, the script is loaded using
178:c:func:`PyImport_Import`.  This routine needs a Python string as its argument,
179which is constructed using the :c:func:`PyUnicode_FromString` data conversion
180routine. ::
181
182   pFunc = PyObject_GetAttrString(pModule, argv[2]);
183   /* pFunc is a new reference */
184
185   if (pFunc && PyCallable_Check(pFunc)) {
186       ...
187   }
188   Py_XDECREF(pFunc);
189
190Once the script is loaded, the name we're looking for is retrieved using
191:c:func:`PyObject_GetAttrString`.  If the name exists, and the object returned is
192callable, you can safely assume that it is a function.  The program then
193proceeds by constructing a tuple of arguments as normal.  The call to the Python
194function is then made with::
195
196   pValue = PyObject_CallObject(pFunc, pArgs);
197
198Upon return of the function, ``pValue`` is either *NULL* or it contains a
199reference to the return value of the function.  Be sure to release the reference
200after examining the value.
201
202
203.. _extending-with-embedding:
204
205Extending Embedded Python
206=========================
207
208Until now, the embedded Python interpreter had no access to functionality from
209the application itself.  The Python API allows this by extending the embedded
210interpreter.  That is, the embedded interpreter gets extended with routines
211provided by the application. While it sounds complex, it is not so bad.  Simply
212forget for a while that the application starts the Python interpreter.  Instead,
213consider the application to be a set of subroutines, and write some glue code
214that gives Python access to those routines, just like you would write a normal
215Python extension.  For example::
216
217   static int numargs=0;
218
219   /* Return the number of arguments of the application command line */
220   static PyObject*
221   emb_numargs(PyObject *self, PyObject *args)
222   {
223       if(!PyArg_ParseTuple(args, ":numargs"))
224           return NULL;
225       return PyLong_FromLong(numargs);
226   }
227
228   static PyMethodDef EmbMethods[] = {
229       {"numargs", emb_numargs, METH_VARARGS,
230        "Return the number of arguments received by the process."},
231       {NULL, NULL, 0, NULL}
232   };
233
234   static PyModuleDef EmbModule = {
235       PyModuleDef_HEAD_INIT, "emb", NULL, -1, EmbMethods,
236       NULL, NULL, NULL, NULL
237   };
238
239   static PyObject*
240   PyInit_emb(void)
241   {
242       return PyModule_Create(&EmbModule);
243   }
244
245Insert the above code just above the :c:func:`main` function. Also, insert the
246following two statements before the call to :c:func:`Py_Initialize`::
247
248   numargs = argc;
249   PyImport_AppendInittab("emb", &PyInit_emb);
250
251These two lines initialize the ``numargs`` variable, and make the
252:func:`emb.numargs` function accessible to the embedded Python interpreter.
253With these extensions, the Python script can do things like
254
255.. code-block:: python
256
257   import emb
258   print("Number of arguments", emb.numargs())
259
260In a real application, the methods will expose an API of the application to
261Python.
262
263.. TODO: threads, code examples do not really behave well if errors happen
264   (what to watch out for)
265
266
267.. _embeddingincplusplus:
268
269Embedding Python in C++
270=======================
271
272It is also possible to embed Python in a C++ program; precisely how this is done
273will depend on the details of the C++ system used; in general you will need to
274write the main program in C++, and use the C++ compiler to compile and link your
275program.  There is no need to recompile Python itself using C++.
276
277
278.. _compiling:
279
280Compiling and Linking under Unix-like systems
281=============================================
282
283It is not necessarily trivial to find the right flags to pass to your
284compiler (and linker) in order to embed the Python interpreter into your
285application, particularly because Python needs to load library modules
286implemented as C dynamic extensions (:file:`.so` files) linked against
287it.
288
289To find out the required compiler and linker flags, you can execute the
290:file:`python{X.Y}-config` script which is generated as part of the
291installation process (a :file:`python3-config` script may also be
292available).  This script has several options, of which the following will
293be directly useful to you:
294
295* ``pythonX.Y-config --cflags`` will give you the recommended flags when
296  compiling:
297
298  .. code-block:: shell-session
299
300     $ /opt/bin/python3.4-config --cflags
301     -I/opt/include/python3.4m -I/opt/include/python3.4m -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
302
303* ``pythonX.Y-config --ldflags`` will give you the recommended flags when
304  linking:
305
306  .. code-block:: shell-session
307
308     $ /opt/bin/python3.4-config --ldflags
309     -L/opt/lib/python3.4/config-3.4m -lpthread -ldl -lutil -lm -lpython3.4m -Xlinker -export-dynamic
310
311.. note::
312   To avoid confusion between several Python installations (and especially
313   between the system Python and your own compiled Python), it is recommended
314   that you use the absolute path to :file:`python{X.Y}-config`, as in the above
315   example.
316
317If this procedure doesn't work for you (it is not guaranteed to work for
318all Unix-like platforms; however, we welcome :ref:`bug reports <reporting-bugs>`)
319you will have to read your system's documentation about dynamic linking and/or
320examine Python's :file:`Makefile` (use :func:`sysconfig.get_makefile_filename`
321to find its location) and compilation
322options.  In this case, the :mod:`sysconfig` module is a useful tool to
323programmatically extract the configuration values that you will want to
324combine together.  For example:
325
326.. code-block:: pycon
327
328   >>> import sysconfig
329   >>> sysconfig.get_config_var('LIBS')
330   '-lpthread -ldl  -lutil'
331   >>> sysconfig.get_config_var('LINKFORSHARED')
332   '-Xlinker -export-dynamic'
333
334
335.. XXX similar documentation for Windows missing
336