[2] | 1 | =======================
|
---|
| 2 | Extending/Embedding FAQ
|
---|
| 3 | =======================
|
---|
| 4 |
|
---|
[391] | 5 | .. only:: html
|
---|
[2] | 6 |
|
---|
[391] | 7 | .. contents::
|
---|
| 8 |
|
---|
[2] | 9 | .. highlight:: c
|
---|
| 10 |
|
---|
| 11 |
|
---|
| 12 | Can I create my own functions in C?
|
---|
| 13 | -----------------------------------
|
---|
| 14 |
|
---|
| 15 | Yes, you can create built-in modules containing functions, variables, exceptions
|
---|
| 16 | and even new types in C. This is explained in the document
|
---|
| 17 | :ref:`extending-index`.
|
---|
| 18 |
|
---|
| 19 | Most intermediate or advanced Python books will also cover this topic.
|
---|
| 20 |
|
---|
| 21 |
|
---|
| 22 | Can I create my own functions in C++?
|
---|
| 23 | -------------------------------------
|
---|
| 24 |
|
---|
| 25 | Yes, using the C compatibility features found in C++. Place ``extern "C" {
|
---|
| 26 | ... }`` around the Python include files and put ``extern "C"`` before each
|
---|
| 27 | function that is going to be called by the Python interpreter. Global or static
|
---|
| 28 | C++ objects with constructors are probably not a good idea.
|
---|
| 29 |
|
---|
| 30 |
|
---|
[391] | 31 | .. _c-wrapper-software:
|
---|
| 32 |
|
---|
[2] | 33 | Writing C is hard; are there any alternatives?
|
---|
| 34 | ----------------------------------------------
|
---|
| 35 |
|
---|
| 36 | There are a number of alternatives to writing your own C extensions, depending
|
---|
| 37 | on what you're trying to do.
|
---|
| 38 |
|
---|
| 39 | .. XXX make sure these all work; mention Cython
|
---|
| 40 |
|
---|
| 41 | If you need more speed, `Psyco <http://psyco.sourceforge.net/>`_ generates x86
|
---|
| 42 | assembly code from Python bytecode. You can use Psyco to compile the most
|
---|
| 43 | time-critical functions in your code, and gain a significant improvement with
|
---|
| 44 | very little effort, as long as you're running on a machine with an
|
---|
| 45 | x86-compatible processor.
|
---|
| 46 |
|
---|
| 47 | `Pyrex <http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/>`_ is a compiler
|
---|
| 48 | that accepts a slightly modified form of Python and generates the corresponding
|
---|
| 49 | C code. Pyrex makes it possible to write an extension without having to learn
|
---|
| 50 | Python's C API.
|
---|
| 51 |
|
---|
| 52 | If you need to interface to some C or C++ library for which no Python extension
|
---|
| 53 | currently exists, you can try wrapping the library's data types and functions
|
---|
| 54 | with a tool such as `SWIG <http://www.swig.org>`_. `SIP
|
---|
| 55 | <http://www.riverbankcomputing.co.uk/software/sip/>`__, `CXX
|
---|
| 56 | <http://cxx.sourceforge.net/>`_ `Boost
|
---|
| 57 | <http://www.boost.org/libs/python/doc/index.html>`_, or `Weave
|
---|
[391] | 58 | <http://www.scipy.org/Weave>`_ are also alternatives for wrapping
|
---|
[2] | 59 | C++ libraries.
|
---|
| 60 |
|
---|
| 61 |
|
---|
| 62 | How can I execute arbitrary Python statements from C?
|
---|
| 63 | -----------------------------------------------------
|
---|
| 64 |
|
---|
[391] | 65 | The highest-level function to do this is :c:func:`PyRun_SimpleString` which takes
|
---|
[2] | 66 | a single string argument to be executed in the context of the module
|
---|
| 67 | ``__main__`` and returns 0 for success and -1 when an exception occurred
|
---|
| 68 | (including ``SyntaxError``). If you want more control, use
|
---|
[391] | 69 | :c:func:`PyRun_String`; see the source for :c:func:`PyRun_SimpleString` in
|
---|
[2] | 70 | ``Python/pythonrun.c``.
|
---|
| 71 |
|
---|
| 72 |
|
---|
| 73 | How can I evaluate an arbitrary Python expression from C?
|
---|
| 74 | ---------------------------------------------------------
|
---|
| 75 |
|
---|
[391] | 76 | Call the function :c:func:`PyRun_String` from the previous question with the
|
---|
| 77 | start symbol :c:data:`Py_eval_input`; it parses an expression, evaluates it and
|
---|
[2] | 78 | returns its value.
|
---|
| 79 |
|
---|
| 80 |
|
---|
| 81 | How do I extract C values from a Python object?
|
---|
| 82 | -----------------------------------------------
|
---|
| 83 |
|
---|
[391] | 84 | That depends on the object's type. If it's a tuple, :c:func:`PyTuple_Size`
|
---|
| 85 | returns its length and :c:func:`PyTuple_GetItem` returns the item at a specified
|
---|
| 86 | index. Lists have similar functions, :c:func:`PyListSize` and
|
---|
| 87 | :c:func:`PyList_GetItem`.
|
---|
[2] | 88 |
|
---|
[391] | 89 | For strings, :c:func:`PyString_Size` returns its length and
|
---|
| 90 | :c:func:`PyString_AsString` a pointer to its value. Note that Python strings may
|
---|
| 91 | contain null bytes so C's :c:func:`strlen` should not be used.
|
---|
[2] | 92 |
|
---|
| 93 | To test the type of an object, first make sure it isn't *NULL*, and then use
|
---|
[391] | 94 | :c:func:`PyString_Check`, :c:func:`PyTuple_Check`, :c:func:`PyList_Check`, etc.
|
---|
[2] | 95 |
|
---|
| 96 | There is also a high-level API to Python objects which is provided by the
|
---|
| 97 | so-called 'abstract' interface -- read ``Include/abstract.h`` for further
|
---|
| 98 | details. It allows interfacing with any kind of Python sequence using calls
|
---|
[391] | 99 | like :c:func:`PySequence_Length`, :c:func:`PySequence_GetItem`, etc.) as well as
|
---|
[2] | 100 | many other useful protocols.
|
---|
| 101 |
|
---|
| 102 |
|
---|
| 103 | How do I use Py_BuildValue() to create a tuple of arbitrary length?
|
---|
| 104 | -------------------------------------------------------------------
|
---|
| 105 |
|
---|
| 106 | You can't. Use ``t = PyTuple_New(n)`` instead, and fill it with objects using
|
---|
| 107 | ``PyTuple_SetItem(t, i, o)`` -- note that this "eats" a reference count of
|
---|
[391] | 108 | ``o``, so you have to :c:func:`Py_INCREF` it. Lists have similar functions
|
---|
[2] | 109 | ``PyList_New(n)`` and ``PyList_SetItem(l, i, o)``. Note that you *must* set all
|
---|
| 110 | the tuple items to some value before you pass the tuple to Python code --
|
---|
| 111 | ``PyTuple_New(n)`` initializes them to NULL, which isn't a valid Python value.
|
---|
| 112 |
|
---|
| 113 |
|
---|
| 114 | How do I call an object's method from C?
|
---|
| 115 | ----------------------------------------
|
---|
| 116 |
|
---|
[391] | 117 | The :c:func:`PyObject_CallMethod` function can be used to call an arbitrary
|
---|
[2] | 118 | method of an object. The parameters are the object, the name of the method to
|
---|
[391] | 119 | call, a format string like that used with :c:func:`Py_BuildValue`, and the
|
---|
[2] | 120 | argument values::
|
---|
| 121 |
|
---|
| 122 | PyObject *
|
---|
| 123 | PyObject_CallMethod(PyObject *object, char *method_name,
|
---|
| 124 | char *arg_format, ...);
|
---|
| 125 |
|
---|
| 126 | This works for any object that has methods -- whether built-in or user-defined.
|
---|
[391] | 127 | You are responsible for eventually :c:func:`Py_DECREF`\ 'ing the return value.
|
---|
[2] | 128 |
|
---|
| 129 | To call, e.g., a file object's "seek" method with arguments 10, 0 (assuming the
|
---|
| 130 | file object pointer is "f")::
|
---|
| 131 |
|
---|
| 132 | res = PyObject_CallMethod(f, "seek", "(ii)", 10, 0);
|
---|
| 133 | if (res == NULL) {
|
---|
| 134 | ... an exception occurred ...
|
---|
| 135 | }
|
---|
| 136 | else {
|
---|
| 137 | Py_DECREF(res);
|
---|
| 138 | }
|
---|
| 139 |
|
---|
[391] | 140 | Note that since :c:func:`PyObject_CallObject` *always* wants a tuple for the
|
---|
[2] | 141 | argument list, to call a function without arguments, pass "()" for the format,
|
---|
| 142 | and to call a function with one argument, surround the argument in parentheses,
|
---|
| 143 | e.g. "(i)".
|
---|
| 144 |
|
---|
| 145 |
|
---|
| 146 | How do I catch the output from PyErr_Print() (or anything that prints to stdout/stderr)?
|
---|
| 147 | ----------------------------------------------------------------------------------------
|
---|
| 148 |
|
---|
| 149 | In Python code, define an object that supports the ``write()`` method. Assign
|
---|
| 150 | this object to :data:`sys.stdout` and :data:`sys.stderr`. Call print_error, or
|
---|
| 151 | just allow the standard traceback mechanism to work. Then, the output will go
|
---|
| 152 | wherever your ``write()`` method sends it.
|
---|
| 153 |
|
---|
| 154 | The easiest way to do this is to use the StringIO class in the standard library.
|
---|
| 155 |
|
---|
| 156 | Sample code and use for catching stdout:
|
---|
| 157 |
|
---|
| 158 | >>> class StdoutCatcher:
|
---|
| 159 | ... def __init__(self):
|
---|
| 160 | ... self.data = ''
|
---|
| 161 | ... def write(self, stuff):
|
---|
| 162 | ... self.data = self.data + stuff
|
---|
| 163 | ...
|
---|
| 164 | >>> import sys
|
---|
| 165 | >>> sys.stdout = StdoutCatcher()
|
---|
| 166 | >>> print 'foo'
|
---|
| 167 | >>> print 'hello world!'
|
---|
| 168 | >>> sys.stderr.write(sys.stdout.data)
|
---|
| 169 | foo
|
---|
| 170 | hello world!
|
---|
| 171 |
|
---|
| 172 |
|
---|
| 173 | How do I access a module written in Python from C?
|
---|
| 174 | --------------------------------------------------
|
---|
| 175 |
|
---|
| 176 | You can get a pointer to the module object as follows::
|
---|
| 177 |
|
---|
| 178 | module = PyImport_ImportModule("<modulename>");
|
---|
| 179 |
|
---|
| 180 | If the module hasn't been imported yet (i.e. it is not yet present in
|
---|
| 181 | :data:`sys.modules`), this initializes the module; otherwise it simply returns
|
---|
| 182 | the value of ``sys.modules["<modulename>"]``. Note that it doesn't enter the
|
---|
| 183 | module into any namespace -- it only ensures it has been initialized and is
|
---|
| 184 | stored in :data:`sys.modules`.
|
---|
| 185 |
|
---|
| 186 | You can then access the module's attributes (i.e. any name defined in the
|
---|
| 187 | module) as follows::
|
---|
| 188 |
|
---|
| 189 | attr = PyObject_GetAttrString(module, "<attrname>");
|
---|
| 190 |
|
---|
[391] | 191 | Calling :c:func:`PyObject_SetAttrString` to assign to variables in the module
|
---|
[2] | 192 | also works.
|
---|
| 193 |
|
---|
| 194 |
|
---|
| 195 | How do I interface to C++ objects from Python?
|
---|
| 196 | ----------------------------------------------
|
---|
| 197 |
|
---|
| 198 | Depending on your requirements, there are many approaches. To do this manually,
|
---|
| 199 | begin by reading :ref:`the "Extending and Embedding" document
|
---|
| 200 | <extending-index>`. Realize that for the Python run-time system, there isn't a
|
---|
| 201 | whole lot of difference between C and C++ -- so the strategy of building a new
|
---|
| 202 | Python type around a C structure (pointer) type will also work for C++ objects.
|
---|
| 203 |
|
---|
[391] | 204 | For C++ libraries, see :ref:`c-wrapper-software`.
|
---|
[2] | 205 |
|
---|
| 206 |
|
---|
| 207 | I added a module using the Setup file and the make fails; why?
|
---|
| 208 | --------------------------------------------------------------
|
---|
| 209 |
|
---|
| 210 | Setup must end in a newline, if there is no newline there, the build process
|
---|
| 211 | fails. (Fixing this requires some ugly shell script hackery, and this bug is so
|
---|
| 212 | minor that it doesn't seem worth the effort.)
|
---|
| 213 |
|
---|
| 214 |
|
---|
| 215 | How do I debug an extension?
|
---|
| 216 | ----------------------------
|
---|
| 217 |
|
---|
| 218 | When using GDB with dynamically loaded extensions, you can't set a breakpoint in
|
---|
| 219 | your extension until your extension is loaded.
|
---|
| 220 |
|
---|
| 221 | In your ``.gdbinit`` file (or interactively), add the command::
|
---|
| 222 |
|
---|
| 223 | br _PyImport_LoadDynamicModule
|
---|
| 224 |
|
---|
| 225 | Then, when you run GDB::
|
---|
| 226 |
|
---|
| 227 | $ gdb /local/bin/python
|
---|
| 228 | gdb) run myscript.py
|
---|
| 229 | gdb) continue # repeat until your extension is loaded
|
---|
| 230 | gdb) finish # so that your extension is loaded
|
---|
| 231 | gdb) br myfunction.c:50
|
---|
| 232 | gdb) continue
|
---|
| 233 |
|
---|
| 234 | I want to compile a Python module on my Linux system, but some files are missing. Why?
|
---|
| 235 | --------------------------------------------------------------------------------------
|
---|
| 236 |
|
---|
| 237 | Most packaged versions of Python don't include the
|
---|
| 238 | :file:`/usr/lib/python2.{x}/config/` directory, which contains various files
|
---|
| 239 | required for compiling Python extensions.
|
---|
| 240 |
|
---|
| 241 | For Red Hat, install the python-devel RPM to get the necessary files.
|
---|
| 242 |
|
---|
| 243 | For Debian, run ``apt-get install python-dev``.
|
---|
| 244 |
|
---|
| 245 |
|
---|
| 246 | What does "SystemError: _PyImport_FixupExtension: module yourmodule not loaded" mean?
|
---|
| 247 | -------------------------------------------------------------------------------------
|
---|
| 248 |
|
---|
| 249 | This means that you have created an extension module named "yourmodule", but
|
---|
| 250 | your module init function does not initialize with that name.
|
---|
| 251 |
|
---|
| 252 | Every module init function will have a line similar to::
|
---|
| 253 |
|
---|
| 254 | module = Py_InitModule("yourmodule", yourmodule_functions);
|
---|
| 255 |
|
---|
| 256 | If the string passed to this function is not the same name as your extension
|
---|
| 257 | module, the :exc:`SystemError` exception will be raised.
|
---|
| 258 |
|
---|
| 259 |
|
---|
| 260 | How do I tell "incomplete input" from "invalid input"?
|
---|
| 261 | ------------------------------------------------------
|
---|
| 262 |
|
---|
| 263 | Sometimes you want to emulate the Python interactive interpreter's behavior,
|
---|
| 264 | where it gives you a continuation prompt when the input is incomplete (e.g. you
|
---|
| 265 | typed the start of an "if" statement or you didn't close your parentheses or
|
---|
| 266 | triple string quotes), but it gives you a syntax error message immediately when
|
---|
| 267 | the input is invalid.
|
---|
| 268 |
|
---|
| 269 | In Python you can use the :mod:`codeop` module, which approximates the parser's
|
---|
| 270 | behavior sufficiently. IDLE uses this, for example.
|
---|
| 271 |
|
---|
[391] | 272 | The easiest way to do it in C is to call :c:func:`PyRun_InteractiveLoop` (perhaps
|
---|
[2] | 273 | in a separate thread) and let the Python interpreter handle the input for
|
---|
[391] | 274 | you. You can also set the :c:func:`PyOS_ReadlineFunctionPointer` to point at your
|
---|
[2] | 275 | custom input function. See ``Modules/readline.c`` and ``Parser/myreadline.c``
|
---|
| 276 | for more hints.
|
---|
| 277 |
|
---|
| 278 | However sometimes you have to run the embedded Python interpreter in the same
|
---|
| 279 | thread as your rest application and you can't allow the
|
---|
[391] | 280 | :c:func:`PyRun_InteractiveLoop` to stop while waiting for user input. The one
|
---|
| 281 | solution then is to call :c:func:`PyParser_ParseString` and test for ``e.error``
|
---|
[2] | 282 | equal to ``E_EOF``, which means the input is incomplete). Here's a sample code
|
---|
| 283 | fragment, untested, inspired by code from Alex Farber::
|
---|
| 284 |
|
---|
| 285 | #include <Python.h>
|
---|
| 286 | #include <node.h>
|
---|
| 287 | #include <errcode.h>
|
---|
| 288 | #include <grammar.h>
|
---|
| 289 | #include <parsetok.h>
|
---|
| 290 | #include <compile.h>
|
---|
| 291 |
|
---|
| 292 | int testcomplete(char *code)
|
---|
| 293 | /* code should end in \n */
|
---|
| 294 | /* return -1 for error, 0 for incomplete, 1 for complete */
|
---|
| 295 | {
|
---|
| 296 | node *n;
|
---|
| 297 | perrdetail e;
|
---|
| 298 |
|
---|
| 299 | n = PyParser_ParseString(code, &_PyParser_Grammar,
|
---|
| 300 | Py_file_input, &e);
|
---|
| 301 | if (n == NULL) {
|
---|
| 302 | if (e.error == E_EOF)
|
---|
| 303 | return 0;
|
---|
| 304 | return -1;
|
---|
| 305 | }
|
---|
| 306 |
|
---|
| 307 | PyNode_Free(n);
|
---|
| 308 | return 1;
|
---|
| 309 | }
|
---|
| 310 |
|
---|
| 311 | Another solution is trying to compile the received string with
|
---|
[391] | 312 | :c:func:`Py_CompileString`. If it compiles without errors, try to execute the
|
---|
| 313 | returned code object by calling :c:func:`PyEval_EvalCode`. Otherwise save the
|
---|
[2] | 314 | input for later. If the compilation fails, find out if it's an error or just
|
---|
| 315 | more input is required - by extracting the message string from the exception
|
---|
| 316 | tuple and comparing it to the string "unexpected EOF while parsing". Here is a
|
---|
| 317 | complete example using the GNU readline library (you may want to ignore
|
---|
| 318 | **SIGINT** while calling readline())::
|
---|
| 319 |
|
---|
| 320 | #include <stdio.h>
|
---|
| 321 | #include <readline.h>
|
---|
| 322 |
|
---|
| 323 | #include <Python.h>
|
---|
| 324 | #include <object.h>
|
---|
| 325 | #include <compile.h>
|
---|
| 326 | #include <eval.h>
|
---|
| 327 |
|
---|
| 328 | int main (int argc, char* argv[])
|
---|
| 329 | {
|
---|
| 330 | int i, j, done = 0; /* lengths of line, code */
|
---|
| 331 | char ps1[] = ">>> ";
|
---|
| 332 | char ps2[] = "... ";
|
---|
| 333 | char *prompt = ps1;
|
---|
| 334 | char *msg, *line, *code = NULL;
|
---|
| 335 | PyObject *src, *glb, *loc;
|
---|
| 336 | PyObject *exc, *val, *trb, *obj, *dum;
|
---|
| 337 |
|
---|
| 338 | Py_Initialize ();
|
---|
| 339 | loc = PyDict_New ();
|
---|
| 340 | glb = PyDict_New ();
|
---|
| 341 | PyDict_SetItemString (glb, "__builtins__", PyEval_GetBuiltins ());
|
---|
| 342 |
|
---|
| 343 | while (!done)
|
---|
| 344 | {
|
---|
| 345 | line = readline (prompt);
|
---|
| 346 |
|
---|
| 347 | if (NULL == line) /* CTRL-D pressed */
|
---|
| 348 | {
|
---|
| 349 | done = 1;
|
---|
| 350 | }
|
---|
| 351 | else
|
---|
| 352 | {
|
---|
| 353 | i = strlen (line);
|
---|
| 354 |
|
---|
| 355 | if (i > 0)
|
---|
| 356 | add_history (line); /* save non-empty lines */
|
---|
| 357 |
|
---|
| 358 | if (NULL == code) /* nothing in code yet */
|
---|
| 359 | j = 0;
|
---|
| 360 | else
|
---|
| 361 | j = strlen (code);
|
---|
| 362 |
|
---|
| 363 | code = realloc (code, i + j + 2);
|
---|
| 364 | if (NULL == code) /* out of memory */
|
---|
| 365 | exit (1);
|
---|
| 366 |
|
---|
| 367 | if (0 == j) /* code was empty, so */
|
---|
| 368 | code[0] = '\0'; /* keep strncat happy */
|
---|
| 369 |
|
---|
| 370 | strncat (code, line, i); /* append line to code */
|
---|
| 371 | code[i + j] = '\n'; /* append '\n' to code */
|
---|
| 372 | code[i + j + 1] = '\0';
|
---|
| 373 |
|
---|
| 374 | src = Py_CompileString (code, "<stdin>", Py_single_input);
|
---|
| 375 |
|
---|
| 376 | if (NULL != src) /* compiled just fine - */
|
---|
| 377 | {
|
---|
| 378 | if (ps1 == prompt || /* ">>> " or */
|
---|
| 379 | '\n' == code[i + j - 1]) /* "... " and double '\n' */
|
---|
| 380 | { /* so execute it */
|
---|
| 381 | dum = PyEval_EvalCode ((PyCodeObject *)src, glb, loc);
|
---|
| 382 | Py_XDECREF (dum);
|
---|
| 383 | Py_XDECREF (src);
|
---|
| 384 | free (code);
|
---|
| 385 | code = NULL;
|
---|
| 386 | if (PyErr_Occurred ())
|
---|
| 387 | PyErr_Print ();
|
---|
| 388 | prompt = ps1;
|
---|
| 389 | }
|
---|
| 390 | } /* syntax error or E_EOF? */
|
---|
| 391 | else if (PyErr_ExceptionMatches (PyExc_SyntaxError))
|
---|
| 392 | {
|
---|
| 393 | PyErr_Fetch (&exc, &val, &trb); /* clears exception! */
|
---|
| 394 |
|
---|
| 395 | if (PyArg_ParseTuple (val, "sO", &msg, &obj) &&
|
---|
| 396 | !strcmp (msg, "unexpected EOF while parsing")) /* E_EOF */
|
---|
| 397 | {
|
---|
| 398 | Py_XDECREF (exc);
|
---|
| 399 | Py_XDECREF (val);
|
---|
| 400 | Py_XDECREF (trb);
|
---|
| 401 | prompt = ps2;
|
---|
| 402 | }
|
---|
| 403 | else /* some other syntax error */
|
---|
| 404 | {
|
---|
| 405 | PyErr_Restore (exc, val, trb);
|
---|
| 406 | PyErr_Print ();
|
---|
| 407 | free (code);
|
---|
| 408 | code = NULL;
|
---|
| 409 | prompt = ps1;
|
---|
| 410 | }
|
---|
| 411 | }
|
---|
| 412 | else /* some non-syntax error */
|
---|
| 413 | {
|
---|
| 414 | PyErr_Print ();
|
---|
| 415 | free (code);
|
---|
| 416 | code = NULL;
|
---|
| 417 | prompt = ps1;
|
---|
| 418 | }
|
---|
| 419 |
|
---|
| 420 | free (line);
|
---|
| 421 | }
|
---|
| 422 | }
|
---|
| 423 |
|
---|
| 424 | Py_XDECREF(glb);
|
---|
| 425 | Py_XDECREF(loc);
|
---|
| 426 | Py_Finalize();
|
---|
| 427 | exit(0);
|
---|
| 428 | }
|
---|
| 429 |
|
---|
| 430 |
|
---|
| 431 | How do I find undefined g++ symbols __builtin_new or __pure_virtual?
|
---|
| 432 | --------------------------------------------------------------------
|
---|
| 433 |
|
---|
| 434 | To dynamically load g++ extension modules, you must recompile Python, relink it
|
---|
| 435 | using g++ (change LINKCC in the Python Modules Makefile), and link your
|
---|
| 436 | extension module using g++ (e.g., ``g++ -shared -o mymodule.so mymodule.o``).
|
---|
| 437 |
|
---|
| 438 |
|
---|
| 439 | Can I create an object class with some methods implemented in C and others in Python (e.g. through inheritance)?
|
---|
| 440 | ----------------------------------------------------------------------------------------------------------------
|
---|
| 441 |
|
---|
| 442 | In Python 2.2, you can inherit from built-in classes such as :class:`int`,
|
---|
| 443 | :class:`list`, :class:`dict`, etc.
|
---|
| 444 |
|
---|
| 445 | The Boost Python Library (BPL, http://www.boost.org/libs/python/doc/index.html)
|
---|
| 446 | provides a way of doing this from C++ (i.e. you can inherit from an extension
|
---|
| 447 | class written in C++ using the BPL).
|
---|
| 448 |
|
---|
| 449 |
|
---|
| 450 | When importing module X, why do I get "undefined symbol: PyUnicodeUCS2*"?
|
---|
| 451 | -------------------------------------------------------------------------
|
---|
| 452 |
|
---|
| 453 | You are using a version of Python that uses a 4-byte representation for Unicode
|
---|
| 454 | characters, but some C extension module you are importing was compiled using a
|
---|
| 455 | Python that uses a 2-byte representation for Unicode characters (the default).
|
---|
| 456 |
|
---|
| 457 | If instead the name of the undefined symbol starts with ``PyUnicodeUCS4``, the
|
---|
| 458 | problem is the reverse: Python was built using 2-byte Unicode characters, and
|
---|
| 459 | the extension module was compiled using a Python with 4-byte Unicode characters.
|
---|
| 460 |
|
---|
| 461 | This can easily occur when using pre-built extension packages. RedHat Linux
|
---|
| 462 | 7.x, in particular, provided a "python2" binary that is compiled with 4-byte
|
---|
| 463 | Unicode. This only causes the link failure if the extension uses any of the
|
---|
| 464 | ``PyUnicode_*()`` functions. It is also a problem if an extension uses any of
|
---|
[391] | 465 | the Unicode-related format specifiers for :c:func:`Py_BuildValue` (or similar) or
|
---|
| 466 | parameter specifications for :c:func:`PyArg_ParseTuple`.
|
---|
[2] | 467 |
|
---|
| 468 | You can check the size of the Unicode character a Python interpreter is using by
|
---|
| 469 | checking the value of sys.maxunicode:
|
---|
| 470 |
|
---|
| 471 | >>> import sys
|
---|
| 472 | >>> if sys.maxunicode > 65535:
|
---|
| 473 | ... print 'UCS4 build'
|
---|
| 474 | ... else:
|
---|
| 475 | ... print 'UCS2 build'
|
---|
| 476 |
|
---|
| 477 | The only way to solve this problem is to use extension modules compiled with a
|
---|
| 478 | Python binary built using the same size for Unicode characters.
|
---|
| 479 |
|
---|
| 480 |
|
---|
| 481 |
|
---|