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