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).
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."