Clone this wiki locally
There are at least 10 different ways to create Python bindings to C/C++ codes. All of which we are discussing here, if we forgot something, please add it here. Please add here advantages and disadvantages of each option.
A list of the rationale for choosing Cython for SAGE is given here: http://www.sagemath.org/doc/html/prog/node35.html
By hand using Python C API
This is the straightforward way, it is well documented here: http://docs.python.org/api/api.html
Produce very nice and clean C file, which you just compile to .so and that's it. Allows to wrap almost any C and C++ code.
The same as Pyrex, but some new nice features added, see DifferencesFromPyrex for details.
SWIG is one of the oldest and most mature methods of wrapping C or C++ code into Python (SWIG works for other target languages as well). It can wrap almost any C and C++ code, including complex templated C++ code. If you have a large (so that hand wrapping is prohibitive) and coarse-grained API, SWIG will likely be your best choice. However, SWIG does have a number or disadvantages compared with Cython. First, SWIG produces a C file, which gets compiled to a .so, but then it also produces a Python wrapper on top of this .so file. For fine grained APIs (where not much is done in each C/C++ call), the overhead of this additional Python wrapper can be significant. Second, with SWIG, the Python wrappers are written for you, so if their design is not exactly what you want, you end up doing more work to create your final Python API.
Similar to SWIG, but only aimed at wrapping C and C++ to Python. Unlike SWIG there is no Python wrapper. Projects moving from SWIG to SIP have shown a 40% increase in speed.
The bindings are fast, but the C++ files compile very slowly and it's very difficult to debug (several pages of C++ errors in templates if you make a mistake in your code).
PyCXX is a C++ wrapper for the Python C API. It is an easy way to write extension modules for Python in C++. All details about the Python C API, including reference counting, is taken care of by the library. The user just has to know Python and C++, and the library exports C++ objects which mirror their Python cpunterparts. Unlike Boost.Python is not merely a wrapping tool but a tool for writing extensions in C++, and as such has the same use cases as Cython. It has soon been around for 20 years and is still actively maintained (version 6.2.6 released Jan 4, 2015), and can be considered very stabile and bug free. A drawback is that PyCXX has different versions for Python 2 and Python 3, which might require you to maintain two versions of your Python code.
Ctypes is included standard in Python 2.5, so it is clearly useful to many Python users. It allows one to call library functions defined in shared object libraries directory from interpreted Python code. For the core of SAGE we have not found a use for this yet. First, when implementing a basic type that needs to be very fast, e.g., GMP integers, the entire implementation absolutely must be compiled - writing it as a combination of Python and C library calls will be way too slow. Second, it is often very painful to convert Python data structures to C data structures and conversely, and there are many opportunities for memory leaks and core dumps.
It generates Boost.Python wrappers.
It's mostly for wrapping fortran files, but it can also wrap C files, even though it's not a very well-known feature.
This works like boost.python, but for the D language, maybe it is possible to call C++ things from D, that would allow to bind C++ to Python, through D. The advantages of PyD over boost.python are described on the upstream webpage - basically it removes all the problems mentioned above that boost.python has.
This works similar to SWIG. It created dynamic link libraries that can be used both from python and c++ via the Python C API. No other files are needed. Its not very well documented but is used in several commercial mmorpg's and is native to the Panda3d engine. The method is pretty robust supporting templates, default parameters, function overloading and some other arcade c++ features.
From the home page: "Robin is a framework that automatically generates Python bindings to C++ libraries. In addition to what other wrapping programs (like "Swig" or "SIP") can do, Robin puts stress on maximal useability and the tightest binding possible."
Seems abandoned; no updates since 2006.
Boost.Python alternative that makes more effective use of recent C++11-capable compilers. The overall syntax and ideology are very similar to Boost.Python, but the implementation only requires a few header files with a a vastly smaller amount of code thanks to C++11 lambda functions, tuples and variadic templates. There is also dedicated support for Python’s buffer protocol and NumPy arrays, which is useful for scientific computing applications.