| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  | .. highlightlang:: c
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .. _embedding:
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | ***************************************
 | 
					
						
							|  |  |  | Embedding Python in Another Application
 | 
					
						
							|  |  |  | ***************************************
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | The previous chapters discussed how to extend Python, that is, how to extend the
 | 
					
						
							|  |  |  | functionality of Python by attaching a library of C functions to it.  It is also
 | 
					
						
							|  |  |  | possible to do it the other way around: enrich your C/C++ application by
 | 
					
						
							|  |  |  | embedding Python in it.  Embedding provides your application with the ability to
 | 
					
						
							|  |  |  | implement some of the functionality of your application in Python rather than C
 | 
					
						
							|  |  |  | or C++. This can be used for many purposes; one example would be to allow users
 | 
					
						
							|  |  |  | to tailor the application to their needs by writing some scripts in Python.  You
 | 
					
						
							|  |  |  | can also use it yourself if some of the functionality can be written in Python
 | 
					
						
							|  |  |  | more easily.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | Embedding Python is similar to extending it, but not quite.  The difference is
 | 
					
						
							|  |  |  | that when you extend Python, the main program of the application is still the
 | 
					
						
							|  |  |  | Python interpreter, while if you embed Python, the main program may have nothing
 | 
					
						
							|  |  |  | to do with Python --- instead, some parts of the application occasionally call
 | 
					
						
							|  |  |  | the Python interpreter to run some Python code.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | So if you are embedding Python, you are providing your own main program.  One of
 | 
					
						
							|  |  |  | the things this main program has to do is initialize the Python interpreter.  At
 | 
					
						
							| 
									
										
										
										
											2010-10-06 10:11:56 +00:00
										 |  |  | the very least, you have to call the function :c:func:`Py_Initialize`.  There are
 | 
					
						
							| 
									
										
										
										
											2008-09-13 17:46:05 +00:00
										 |  |  | optional calls to pass command line arguments to Python.  Then later you can
 | 
					
						
							|  |  |  | call the interpreter from any part of the application.
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | There are several different ways to call the interpreter: you can pass a string
 | 
					
						
							| 
									
										
										
										
											2010-10-06 10:11:56 +00:00
										 |  |  | containing Python statements to :c:func:`PyRun_SimpleString`, or you can pass a
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  | stdio file pointer and a file name (for identification in error messages only)
 | 
					
						
							| 
									
										
										
										
											2010-10-06 10:11:56 +00:00
										 |  |  | to :c:func:`PyRun_SimpleFile`.  You can also call the lower-level operations
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  | described in the previous chapters to construct and use Python objects.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .. seealso::
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |    :ref:`c-api-index`
 | 
					
						
							|  |  |  |       The details of Python's C interface are given in this manual. A great deal of
 | 
					
						
							|  |  |  |       necessary information can be found here.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .. _high-level-embedding:
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | Very High Level Embedding
 | 
					
						
							|  |  |  | =========================
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | The simplest form of embedding Python is the use of the very high level
 | 
					
						
							|  |  |  | interface. This interface is intended to execute a Python script without needing
 | 
					
						
							|  |  |  | to interact with the application directly. This can for example be used to
 | 
					
						
							|  |  |  | perform some operation on a file. ::
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |    #include <Python.h>
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |    int
 | 
					
						
							|  |  |  |    main(int argc, char *argv[])
 | 
					
						
							|  |  |  |    {
 | 
					
						
							| 
									
										
										
										
											2014-08-01 12:28:49 +02:00
										 |  |  |        wchar_t *program = Py_DecodeLocale(argv[0], NULL);
 | 
					
						
							|  |  |  |        if (program == NULL) {
 | 
					
						
							|  |  |  |            fprintf(stderr, "Fatal error: cannot decode argv[0]\n");
 | 
					
						
							|  |  |  |            exit(1);
 | 
					
						
							|  |  |  |        }
 | 
					
						
							|  |  |  |        Py_SetProgramName(program);  /* optional but recommended */
 | 
					
						
							|  |  |  |        Py_Initialize();
 | 
					
						
							|  |  |  |        PyRun_SimpleString("from time import time,ctime\n"
 | 
					
						
							|  |  |  |                           "print('Today is', ctime(time()))\n");
 | 
					
						
							|  |  |  |        Py_Finalize();
 | 
					
						
							|  |  |  |        PyMem_RawFree(program);
 | 
					
						
							|  |  |  |        return 0;
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  |    }
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-11-02 07:34:37 +01:00
										 |  |  | The :c:func:`Py_SetProgramName` function should be called before
 | 
					
						
							|  |  |  | :c:func:`Py_Initialize` to inform the interpreter about paths to Python run-time
 | 
					
						
							|  |  |  | libraries.  Next, the Python interpreter is initialized with
 | 
					
						
							|  |  |  | :c:func:`Py_Initialize`, followed by the execution of a hard-coded Python script
 | 
					
						
							|  |  |  | that prints the date and time.  Afterwards, the :c:func:`Py_Finalize` call shuts
 | 
					
						
							|  |  |  | the interpreter down, followed by the end of the program.  In a real program,
 | 
					
						
							|  |  |  | you may want to get the Python script from another source, perhaps a text-editor
 | 
					
						
							|  |  |  | routine, a file, or a database.  Getting the Python code from a file can better
 | 
					
						
							|  |  |  | be done by using the :c:func:`PyRun_SimpleFile` function, which saves you the
 | 
					
						
							|  |  |  | trouble of allocating memory space and loading the file contents.
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .. _lower-level-embedding:
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | Beyond Very High Level Embedding: An overview
 | 
					
						
							|  |  |  | =============================================
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | The high level interface gives you the ability to execute arbitrary pieces of
 | 
					
						
							|  |  |  | Python code from your application, but exchanging data values is quite
 | 
					
						
							|  |  |  | cumbersome to say the least. If you want that, you should use lower level calls.
 | 
					
						
							|  |  |  | At the cost of having to write more C code, you can achieve almost anything.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | It should be noted that extending Python and embedding Python is quite the same
 | 
					
						
							|  |  |  | activity, despite the different intent. Most topics discussed in the previous
 | 
					
						
							|  |  |  | chapters are still valid. To show this, consider what the extension code from
 | 
					
						
							|  |  |  | Python to C really does:
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #. Convert data values from Python to C,
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #. Perform a function call to a C routine using the converted values, and
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #. Convert the data values from the call from C to Python.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | When embedding Python, the interface code does:
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #. Convert data values from C to Python,
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #. Perform a function call to a Python interface routine using the converted
 | 
					
						
							|  |  |  |    values, and
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #. Convert the data values from the call from Python to C.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | As you can see, the data conversion steps are simply swapped to accommodate the
 | 
					
						
							|  |  |  | different direction of the cross-language transfer. The only difference is the
 | 
					
						
							|  |  |  | routine that you call between both data conversions. When extending, you call a
 | 
					
						
							|  |  |  | C routine, when embedding, you call a Python routine.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | This chapter will not discuss how to convert data from Python to C and vice
 | 
					
						
							|  |  |  | versa.  Also, proper use of references and dealing with errors is assumed to be
 | 
					
						
							|  |  |  | understood.  Since these aspects do not differ from extending the interpreter,
 | 
					
						
							|  |  |  | you can refer to earlier chapters for the required information.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .. _pure-embedding:
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | Pure Embedding
 | 
					
						
							|  |  |  | ==============
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | The first program aims to execute a function in a Python script. Like in the
 | 
					
						
							|  |  |  | section about the very high level interface, the Python interpreter does not
 | 
					
						
							|  |  |  | directly interact with the application (but that will change in the next
 | 
					
						
							|  |  |  | section).
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | The code to run a function defined in a Python script is:
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .. literalinclude:: ../includes/run-func.c
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | This code loads a Python script using ``argv[1]``, and calls the function named
 | 
					
						
							|  |  |  | in ``argv[2]``.  Its integer arguments are the other values of the ``argv``
 | 
					
						
							| 
									
										
										
										
											2011-11-30 21:19:21 +01:00
										 |  |  | array.  If you :ref:`compile and link <compiling>` this program (let's call
 | 
					
						
							|  |  |  | the finished executable :program:`call`), and use it to execute a Python
 | 
					
						
							| 
									
										
										
										
											2013-02-22 07:46:22 +02:00
										 |  |  | script, such as:
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .. code-block:: python
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  |    def multiply(a,b):
 | 
					
						
							| 
									
										
										
										
											2007-09-04 07:15:32 +00:00
										 |  |  |        print("Will compute", a, "times", b)
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  |        c = 0
 | 
					
						
							|  |  |  |        for i in range(0, a):
 | 
					
						
							|  |  |  |            c = c + b
 | 
					
						
							|  |  |  |        return c
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | then the result should be::
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |    $ call multiply multiply 3 2
 | 
					
						
							|  |  |  |    Will compute 3 times 2
 | 
					
						
							|  |  |  |    Result of call: 6
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | Although the program is quite large for its functionality, most of the code is
 | 
					
						
							|  |  |  | for data conversion between Python and C, and for error reporting.  The
 | 
					
						
							| 
									
										
											  
											
												Merged revisions 59605-59624 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
  r59606 | georg.brandl | 2007-12-29 11:57:00 +0100 (Sat, 29 Dec 2007) | 2 lines
  Some cleanup in the docs.
........
  r59611 | martin.v.loewis | 2007-12-29 19:49:21 +0100 (Sat, 29 Dec 2007) | 2 lines
  Bug #1699: Define _BSD_SOURCE only on OpenBSD.
........
  r59612 | raymond.hettinger | 2007-12-29 23:09:34 +0100 (Sat, 29 Dec 2007) | 1 line
  Simpler documentation for itertools.tee().  Should be backported.
........
  r59613 | raymond.hettinger | 2007-12-29 23:16:24 +0100 (Sat, 29 Dec 2007) | 1 line
  Improve docs for itertools.groupby().  The use of xrange(0) to create a unique object is less obvious than object().
........
  r59620 | christian.heimes | 2007-12-31 15:47:07 +0100 (Mon, 31 Dec 2007) | 3 lines
  Added wininst-9.0.exe executable for VS 2008
  Integrated bdist_wininst into PCBuild9 directory
........
  r59621 | christian.heimes | 2007-12-31 15:51:18 +0100 (Mon, 31 Dec 2007) | 1 line
  Moved PCbuild directory to PC/VS7.1
........
  r59622 | christian.heimes | 2007-12-31 15:59:26 +0100 (Mon, 31 Dec 2007) | 1 line
  Fix paths for build bot
........
  r59623 | christian.heimes | 2007-12-31 16:02:41 +0100 (Mon, 31 Dec 2007) | 1 line
  Fix paths for build bot, part 2
........
  r59624 | christian.heimes | 2007-12-31 16:18:55 +0100 (Mon, 31 Dec 2007) | 1 line
  Renamed PCBuild9 directory to PCBuild
........
											
										 
											2007-12-31 16:14:33 +00:00
										 |  |  | interesting part with respect to embedding Python starts with ::
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  |    Py_Initialize();
 | 
					
						
							| 
									
										
										
										
											2014-08-01 12:28:49 +02:00
										 |  |  |    pName = PyUnicode_DecodeFSDefault(argv[1]);
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  |    /* Error checking of pName left out */
 | 
					
						
							|  |  |  |    pModule = PyImport_Import(pName);
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | After initializing the interpreter, the script is loaded using
 | 
					
						
							| 
									
										
										
										
											2010-10-06 10:11:56 +00:00
										 |  |  | :c:func:`PyImport_Import`.  This routine needs a Python string as its argument,
 | 
					
						
							| 
									
										
										
										
											2012-07-01 09:43:20 +02:00
										 |  |  | which is constructed using the :c:func:`PyUnicode_FromString` data conversion
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  | routine. ::
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |    pFunc = PyObject_GetAttrString(pModule, argv[2]);
 | 
					
						
							|  |  |  |    /* pFunc is a new reference */
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |    if (pFunc && PyCallable_Check(pFunc)) {
 | 
					
						
							|  |  |  |        ...
 | 
					
						
							|  |  |  |    }
 | 
					
						
							|  |  |  |    Py_XDECREF(pFunc);
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | Once the script is loaded, the name we're looking for is retrieved using
 | 
					
						
							| 
									
										
										
										
											2010-10-06 10:11:56 +00:00
										 |  |  | :c:func:`PyObject_GetAttrString`.  If the name exists, and the object returned is
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  | callable, you can safely assume that it is a function.  The program then
 | 
					
						
							|  |  |  | proceeds by constructing a tuple of arguments as normal.  The call to the Python
 | 
					
						
							|  |  |  | function is then made with::
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |    pValue = PyObject_CallObject(pFunc, pArgs);
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | Upon return of the function, ``pValue`` is either *NULL* or it contains a
 | 
					
						
							|  |  |  | reference to the return value of the function.  Be sure to release the reference
 | 
					
						
							|  |  |  | after examining the value.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .. _extending-with-embedding:
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | Extending Embedded Python
 | 
					
						
							|  |  |  | =========================
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | Until now, the embedded Python interpreter had no access to functionality from
 | 
					
						
							|  |  |  | the application itself.  The Python API allows this by extending the embedded
 | 
					
						
							|  |  |  | interpreter.  That is, the embedded interpreter gets extended with routines
 | 
					
						
							|  |  |  | provided by the application. While it sounds complex, it is not so bad.  Simply
 | 
					
						
							|  |  |  | forget for a while that the application starts the Python interpreter.  Instead,
 | 
					
						
							|  |  |  | consider the application to be a set of subroutines, and write some glue code
 | 
					
						
							|  |  |  | that gives Python access to those routines, just like you would write a normal
 | 
					
						
							|  |  |  | Python extension.  For example::
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |    static int numargs=0;
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |    /* Return the number of arguments of the application command line */
 | 
					
						
							|  |  |  |    static PyObject*
 | 
					
						
							|  |  |  |    emb_numargs(PyObject *self, PyObject *args)
 | 
					
						
							|  |  |  |    {
 | 
					
						
							|  |  |  |        if(!PyArg_ParseTuple(args, ":numargs"))
 | 
					
						
							|  |  |  |            return NULL;
 | 
					
						
							| 
									
										
										
										
											2010-11-26 11:55:48 +00:00
										 |  |  |        return PyLong_FromLong(numargs);
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  |    }
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |    static PyMethodDef EmbMethods[] = {
 | 
					
						
							|  |  |  |        {"numargs", emb_numargs, METH_VARARGS,
 | 
					
						
							|  |  |  |         "Return the number of arguments received by the process."},
 | 
					
						
							|  |  |  |        {NULL, NULL, 0, NULL}
 | 
					
						
							|  |  |  |    };
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2008-12-07 22:45:56 +00:00
										 |  |  |    static PyModuleDef EmbModule = {
 | 
					
						
							|  |  |  |        PyModuleDef_HEAD_INIT, "emb", NULL, -1, EmbMethods,
 | 
					
						
							|  |  |  |        NULL, NULL, NULL, NULL
 | 
					
						
							|  |  |  |    };
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2008-12-09 23:48:44 +00:00
										 |  |  |    static PyObject*
 | 
					
						
							|  |  |  |    PyInit_emb(void)
 | 
					
						
							|  |  |  |    {
 | 
					
						
							|  |  |  |        return PyModule_Create(&EmbModule);
 | 
					
						
							|  |  |  |    }
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2010-10-06 10:11:56 +00:00
										 |  |  | Insert the above code just above the :c:func:`main` function. Also, insert the
 | 
					
						
							|  |  |  | following two statements before the call to :c:func:`Py_Initialize`::
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  |    numargs = argc;
 | 
					
						
							| 
									
										
										
										
											2008-12-09 23:48:44 +00:00
										 |  |  |    PyImport_AppendInittab("emb", &PyInit_emb);
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | These two lines initialize the ``numargs`` variable, and make the
 | 
					
						
							|  |  |  | :func:`emb.numargs` function accessible to the embedded Python interpreter.
 | 
					
						
							| 
									
										
										
										
											2013-02-22 07:46:22 +02:00
										 |  |  | With these extensions, the Python script can do things like
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .. code-block:: python
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  |    import emb
 | 
					
						
							| 
									
										
										
										
											2007-09-04 07:15:32 +00:00
										 |  |  |    print("Number of arguments", emb.numargs())
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | In a real application, the methods will expose an API of the application to
 | 
					
						
							|  |  |  | Python.
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												Merged revisions 59605-59624 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
  r59606 | georg.brandl | 2007-12-29 11:57:00 +0100 (Sat, 29 Dec 2007) | 2 lines
  Some cleanup in the docs.
........
  r59611 | martin.v.loewis | 2007-12-29 19:49:21 +0100 (Sat, 29 Dec 2007) | 2 lines
  Bug #1699: Define _BSD_SOURCE only on OpenBSD.
........
  r59612 | raymond.hettinger | 2007-12-29 23:09:34 +0100 (Sat, 29 Dec 2007) | 1 line
  Simpler documentation for itertools.tee().  Should be backported.
........
  r59613 | raymond.hettinger | 2007-12-29 23:16:24 +0100 (Sat, 29 Dec 2007) | 1 line
  Improve docs for itertools.groupby().  The use of xrange(0) to create a unique object is less obvious than object().
........
  r59620 | christian.heimes | 2007-12-31 15:47:07 +0100 (Mon, 31 Dec 2007) | 3 lines
  Added wininst-9.0.exe executable for VS 2008
  Integrated bdist_wininst into PCBuild9 directory
........
  r59621 | christian.heimes | 2007-12-31 15:51:18 +0100 (Mon, 31 Dec 2007) | 1 line
  Moved PCbuild directory to PC/VS7.1
........
  r59622 | christian.heimes | 2007-12-31 15:59:26 +0100 (Mon, 31 Dec 2007) | 1 line
  Fix paths for build bot
........
  r59623 | christian.heimes | 2007-12-31 16:02:41 +0100 (Mon, 31 Dec 2007) | 1 line
  Fix paths for build bot, part 2
........
  r59624 | christian.heimes | 2007-12-31 16:18:55 +0100 (Mon, 31 Dec 2007) | 1 line
  Renamed PCBuild9 directory to PCBuild
........
											
										 
											2007-12-31 16:14:33 +00:00
										 |  |  | .. TODO: threads, code examples do not really behave well if errors happen
 | 
					
						
							|  |  |  |    (what to watch out for)
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | .. _embeddingincplusplus:
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | Embedding Python in C++
 | 
					
						
							|  |  |  | =======================
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | It is also possible to embed Python in a C++ program; precisely how this is done
 | 
					
						
							|  |  |  | will depend on the details of the C++ system used; in general you will need to
 | 
					
						
							|  |  |  | write the main program in C++, and use the C++ compiler to compile and link your
 | 
					
						
							|  |  |  | program.  There is no need to recompile Python itself using C++.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2011-11-30 21:19:21 +01:00
										 |  |  | .. _compiling:
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2011-11-30 21:19:21 +01:00
										 |  |  | Compiling and Linking under Unix-like systems
 | 
					
						
							|  |  |  | =============================================
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2011-11-30 21:19:21 +01:00
										 |  |  | It is not necessarily trivial to find the right flags to pass to your
 | 
					
						
							|  |  |  | compiler (and linker) in order to embed the Python interpreter into your
 | 
					
						
							|  |  |  | application, particularly because Python needs to load library modules
 | 
					
						
							|  |  |  | implemented as C dynamic extensions (:file:`.so` files) linked against
 | 
					
						
							|  |  |  | it.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | To find out the required compiler and linker flags, you can execute the
 | 
					
						
							|  |  |  | :file:`python{X.Y}-config` script which is generated as part of the
 | 
					
						
							| 
									
										
										
										
											2012-01-15 02:31:58 +01:00
										 |  |  | installation process (a :file:`python3-config` script may also be
 | 
					
						
							| 
									
										
										
										
											2011-11-30 21:19:21 +01:00
										 |  |  | available).  This script has several options, of which the following will
 | 
					
						
							|  |  |  | be directly useful to you:
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | * ``pythonX.Y-config --cflags`` will give you the recommended flags when
 | 
					
						
							|  |  |  |   compiling::
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-05-26 18:57:00 -07:00
										 |  |  |    $ /opt/bin/python3.4-config --cflags
 | 
					
						
							|  |  |  |    -I/opt/include/python3.4m -I/opt/include/python3.4m -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
 | 
					
						
							| 
									
										
										
										
											2011-11-30 21:19:21 +01:00
										 |  |  | 
 | 
					
						
							|  |  |  | * ``pythonX.Y-config --ldflags`` will give you the recommended flags when
 | 
					
						
							|  |  |  |   linking::
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-05-26 18:57:00 -07:00
										 |  |  |    $ /opt/bin/python3.4-config --ldflags
 | 
					
						
							|  |  |  |    -L/opt/lib/python3.4/config-3.4m -lpthread -ldl -lutil -lm -lpython3.4m -Xlinker -export-dynamic
 | 
					
						
							| 
									
										
										
										
											2011-11-30 21:19:21 +01:00
										 |  |  | 
 | 
					
						
							|  |  |  | .. note::
 | 
					
						
							|  |  |  |    To avoid confusion between several Python installations (and especially
 | 
					
						
							|  |  |  |    between the system Python and your own compiled Python), it is recommended
 | 
					
						
							|  |  |  |    that you use the absolute path to :file:`python{X.Y}-config`, as in the above
 | 
					
						
							|  |  |  |    example.
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | If this procedure doesn't work for you (it is not guaranteed to work for
 | 
					
						
							| 
									
										
										
										
											2012-01-15 02:31:58 +01:00
										 |  |  | all Unix-like platforms; however, we welcome :ref:`bug reports <reporting-bugs>`)
 | 
					
						
							|  |  |  | you will have to read your system's documentation about dynamic linking and/or
 | 
					
						
							|  |  |  | examine Python's :file:`Makefile` (use :func:`sysconfig.get_makefile_filename`
 | 
					
						
							|  |  |  | to find its location) and compilation
 | 
					
						
							| 
									
										
										
										
											2011-11-30 21:19:21 +01:00
										 |  |  | options.  In this case, the :mod:`sysconfig` module is a useful tool to
 | 
					
						
							|  |  |  | programmatically extract the configuration values that you will want to
 | 
					
						
							| 
									
										
										
										
											2013-06-24 14:22:09 -07:00
										 |  |  | combine together.  For example:
 | 
					
						
							| 
									
										
										
										
											2013-02-22 07:46:22 +02:00
										 |  |  | 
 | 
					
						
							|  |  |  | .. code-block:: python
 | 
					
						
							| 
									
										
										
										
											2011-11-30 21:19:21 +01:00
										 |  |  | 
 | 
					
						
							|  |  |  |    >>> import sysconfig
 | 
					
						
							| 
									
										
										
										
											2013-06-24 14:22:09 -07:00
										 |  |  |    >>> sysconfig.get_config_var('LIBS')
 | 
					
						
							|  |  |  |    '-lpthread -ldl  -lutil'
 | 
					
						
							| 
									
										
										
										
											2011-11-30 21:19:21 +01:00
										 |  |  |    >>> sysconfig.get_config_var('LINKFORSHARED')
 | 
					
						
							| 
									
										
										
										
											2007-08-15 14:28:22 +00:00
										 |  |  |    '-Xlinker -export-dynamic'
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2011-11-30 21:19:21 +01:00
										 |  |  | .. XXX similar documentation for Windows missing
 |