Cython: A dialect of Python that can freely mix Python and C datatypes. Gives a modest speedup with a few type annotations for classes, and can be quite a bit faster if you give your innermost loop all C types to operate on. Pretty much CPython only at this time.
SWIG: A sort of interface/glue language for matching up a C library with a potentially large list of higher level languages, including CPython.
Allows you to call individual C functions and access individual C
datatypes. Not blazing in CPython unless you spend a lot of time in
the C code. Can be a bit brittle. Also works on Pypy; in fact Pypy
uses it a lot today.
extension module: Pretty standard stuff for CPython - this is
how much of the CPython standard library is put together. Some
but not all of these work with Pypy if you use cpyext. In short,
with this you're writing a module with a bunch of boiler plate, in
C, but it can be called from CPython.
new foreign function interface coming from the Pypy project. They
have it working with CPython and Pypy now.
It is like ctypes, but is less brittle.
Pypy: This isn't really a way
calling C or C++, but it's got almost as much speed as C for a lot
of pure python code. If you don't have a lot of C extension modules
you require, then Pypy might be a good option for you.
A very portable way of interacting with another process in
not-necessarily-the-same-language. Can be used with just about any
language in the child process. Not blazing fast, unless you spend
little time passing data back and forth. Pretty much all data
exchanged has to be serialized to ASCII or something, but it is so
portable and simple and loosely coupled that it's worth thinking
about. Note that although this is a bit of a mess on Windows (slow,
exit statuses unreliable, non-columnar tool output), it works quite
well on *ix.
experimental translator that creates C++ from implicitly static
not tried Boost.Python yet, but it looks kind of like a ctypes or CFFI for C++.
SIP sounds interesting; it's used
to automatically generate bindings for Qt/KDE, which means it handles some pretty huge stuff.
Don't rush to coding in C or other forms of optimization - C is much
more expensive in terms of programmer time and is prone to subtle, hard
to find bugs. Run your code in Pure Python first, to get the program
producing correct results at whatever speed, and then if you find that
the program is too slow, profile the program to decide which part(s)
need to be redone in one of the ways listed above. Usually you'll only
need 0-2% of your program to be done in something other than pure python
- you may as well reap the programmer-time savings for as much of the code
as is practical.