.. highlightlang:: c

Porting Extension Modules to Python 3

Conditional compilation

The easiest way to compile only some code for Python 3 is to check if :c:macro:`PY_MAJOR_VERSION` is greater than or equal to 3.

#if PY_MAJOR_VERSION >= 3
#define IS_PY3K
#endif

API functions that are not present can be aliased to their equivalents within conditional blocks.

Changes to Object APIs

Python 3 merged together some types with similar functions while cleanly separating others.

str/unicode Unification

Python 3's :func:`str` type is equivalent to Python 2's :func:`unicode`; the C functions are called PyUnicode_* for both. The old 8-bit string type has become :func:`bytes`, with C functions called PyBytes_*. Python 2.6 and later provide a compatibility header, :file:`bytesobject.h`, mapping PyBytes names to PyString ones. For best compatibility with Python 3, :c:type:`PyUnicode` should be used for textual data and :c:type:`PyBytes` for binary data. It's also important to remember that :c:type:`PyBytes` and :c:type:`PyUnicode` in Python 3 are not interchangeable like :c:type:`PyString` and :c:type:`PyUnicode` are in Python 2. The following example shows best practices with regards to :c:type:`PyUnicode`, :c:type:`PyString`, and :c:type:`PyBytes`.

#include "stdlib.h"
#include "Python.h"
#include "bytesobject.h"

/* text example */
static PyObject *
say_hello(PyObject *self, PyObject *args) {
 PyObject *name, *result;

 if (!PyArg_ParseTuple(args, "U:say_hello", &name))
 return NULL;

 result = PyUnicode_FromFormat("Hello, %S!", name);
 return result;
}

/* just a forward */
static char * do_encode(PyObject *);

/* bytes example */
static PyObject *
encode_object(PyObject *self, PyObject *args) {
 char *encoded;
 PyObject *result, *myobj;

 if (!PyArg_ParseTuple(args, "O:encode_object", &myobj))
 return NULL;

 encoded = do_encode(myobj);
 if (encoded == NULL)
 return NULL;
 result = PyBytes_FromString(encoded);
 free(encoded);
 return result;
}

long/int Unification

Python 3 has only one integer type, :func:`int`. But it actually corresponds to Python 2's :func:`long` type—the :func:`int` type used in Python 2 was removed. In the C-API, PyInt_* functions are replaced by their PyLong_* equivalents.

Module initialization and state

Python 3 has a revamped extension module initialization system. (See

CObject replaced with Capsule

The :c:type:`Capsule` object was introduced in Python 3.1 and 2.7 to replace :c:type:`CObject`. CObjects were useful, but the :c:type:`CObject` API was problematic: it didn't permit distinguishing between valid CObjects, which allowed mismatched CObjects to crash the interpreter, and some of its APIs relied on undefined behavior in C. (For further reading on the rationale behind Capsules, please see :issue:`5630`.)

If you're currently using CObjects, and you want to migrate to 3.1 or newer, you'll need to switch to Capsules. :c:type:`CObject` was deprecated in 3.1 and 2.7 and completely removed in Python 3.2. If you only support 2.7, or 3.1 and above, you can simply switch to :c:type:`Capsule`. If you need to support Python 3.0, or versions of Python earlier than 2.7, you'll have to support both CObjects and Capsules. (Note that Python 3.0 is no longer supported, and it is not recommended for production use.)

The following example header file :file:`capsulethunk.h` may solve the problem for you. Simply write your code against the :c:type:`Capsule` API and include this header file after :file:`Python.h`. Your code will automatically use Capsules in versions of Python with Capsules, and switch to CObjects when Capsules are unavailable.

:file:`capsulethunk.h` simulates Capsules using CObjects. However, :c:type:`CObject` provides no place to store the capsule's "name". As a result the simulated :c:type:`Capsule` objects created by :file:`capsulethunk.h` behave slightly differently from real Capsules. Specifically:

• The name parameter passed in to :c:func:`PyCapsule_New` is ignored.
• The name parameter passed in to :c:func:`PyCapsule_IsValid` and :c:func:`PyCapsule_GetPointer` is ignored, and no error checking of the name is performed.
• :c:func:`PyCapsule_GetName` always returns NULL.
• :c:func:`PyCapsule_SetName` always raises an exception and returns failure. (Since there's no way to store a name in a CObject, noisy failure of :c:func:`PyCapsule_SetName` was deemed preferable to silent failure here. If this is inconvenient, feel free to modify your local copy as you see fit.)

You can find :file:`capsulethunk.h` in the Python source distribution as :source:`Doc/includes/capsulethunk.h`. We also include it here for your convenience:

.. literalinclude:: ../includes/capsulethunk.h

Other options

If you are writing a new extension module, you might consider /python_sourcecode/python3.7.4/blob/master/Doc/howto/cporting.rst