Linking models are extremely important when considering how we can extend or embed things in native applications. There are two main linking models for Cython:

Fully embedded Python within C/C++ code, which looks like the following screenshot:

Using this method of embedding the Python runtime into a native application means you initiate execution of code directly from any point in your C/C++ code, as opposed to the Chapter 1, Cython Won't Bite where we had to run the Python interpreter and call an import to execute native code.

For the sake of completeness, here is the import model of using Cython:

This would be a more Pythonic approach to Cython, and will be helpful if your code base is mostly Python. We will review an example of the Python lxml module, which provides a Cython backend, later in this book, and we can compare it to the native Python backend to review the speed and execution of both code bases to perform the same task.

The cdef keyword tells the compiler that this statement is a native C type or native function. Remember from Chapter 1, Cython Won't Bite that we used this line to declare the C prototype function:

cdef int AddFunction(int, int)

This is the line that let us wrap the native C function into a Python callable using the Python def keyword. We can use this in many contexts, for example, we can declare normal variables for use within a function to speed up execution:

def square(int x):
    return x ** 2

This is a trivial example, but it will tell the compiler that we will always be squaring an integer. However, for normal Python code, it's a little more complicated as Python has to worry a lot more about losing precision when it comes to handling many different types. But in this case, we know exactly what the type is and how it can be handled.

You might also have noticed that this is a simple def function, but because it will be fed to the Cython compiler, this will work just...

The typedef in C/C++ code allows the programmer to give a new name or alias to any type. For example, one could typedef an int to myint. Or you can just simply typedef a struct so that you don't have to refer to the struct with the keyword struct every time. For example, consider this C struct and typedef:

struct foobar {
  int x;
  char * y;
};
typedef struct foobar foobar_t;

In Cython, this can be described by the following:

cdef struct foobar:
    int x
    char * y
ctypedef foobar foobar_t

Note we can also typedef pointer types as below:

ctypedef int * int_ptr

We can also typedef function C/C++ pointers, as follows:

typedef void (*cfptr) (int)

In Cython, this will be as follows:

ctypedef void (*cfptr)(int)

Using the function pointer is just as you would expect:

cdef cfptr myfunctionptr = &myfunc

There is some magic going on here with function pointers as it's simply not safe for raw Python code to directly call a Python function or vice versa. Cython understands...

This is a very powerful keyword in Cython. It allows any cdef declaration with the public modifier to output a respective C/C++ header with the relative declaration accessible from C/C++. For example, we can declare:

cdef public struct CythonStruct:
    size_t number_of_elements;
    char ** elements;

Once the compiler handles this, you will have an output of cython_input.h:

 struct CythonStruct {
    size_t number_of_elements;
    char ** elements;
};

The main caveat, if you're going to call the Python public declarations directly from C, is that, if your link model is fully embedded and linked against libpython.so, you need to use some boilerplate code to initialize Python correctly:

#include <Python.h>

int main(int argc, char **argv) {
    Py_Initialize ();
    // code in here
    Py_Finalize ();
    return 0;
}

And before calling anything with the function, you need to initialize the Python module example if you have a cythonfile.pyx file, and compile it with the...

So far, we have seen two different function declarations in Cython, def and cdef, to define functions. There is one more declaration—cpdef. The def is a Python-only function, so it is only callable from Python or Cython code blocks; calling from C does not work. The cdef is the opposite; this means that it's callable from C and not from Python. For example, if we create a function such as:

cpdef public test (int x):
   …
  return 1

It will generate the following function prototype:

__PYX_EXTERN_C DL_IMPORT(PyObject) *test(int, int __pyx_skip_dispatch);

The public keyword will make sure we generate the needed header so that we can call it from C. Calling from pure Python, we can work with this as if it was just any other Python function. The drawback of using cpdef is that the native return type is PyObject *, which requires you to know exactly what the return type is and consult the Python API documentation to access the data. I prefer keeping bindings between the languages simpler...

An example of everything brought together is reusing the Python logging module directly from C. We want a few macros, such as info, error, and debug that can all handle a variable number of arguments and works as if we are calling a simple printf method.

To achieve this, we must make a Python logging backend for our C/C++ code. We need an initialization function to tell Python about our output logfile, and some wrappers for each info, error, and debug. We can simply write the public cdef wrappers as:

import logging

cdef public void initLoggingWithLogFile(const char * logfile):
    logging.basicConfig(filename = logfile,
                        level = logging.DEBUG,
                        format = '%(levelname)s %(asctime)s: %(message)s',
                        datefmt = '%m/%d/%Y %I:%M:%S')

cdef public void python_info(char * message):
    logging.info(message)

cdef public void python_debug(char * message):
    logging.debug(message)

cdef public void...