Options that come to mind:
  1. 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.
  2. SWIG: A sort of interface/glue language for matching up a C library with a potentially large list of higher level languages, including CPython.
  3. ctypes: 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.
  4. C 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.
  5. CFFI: A 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.
  6. 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.
  7. subprocess: 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.
  8. Shedskin - experimental translator that creates C++ from implicitly static Python code.
  9. Boost.Python: I've not tried Boost.Python yet, but it looks kind of like a ctypes or CFFI for C++.
  10. SIP sounds interesting; it's used to automatically generate bindings for Qt/KDE, which means it handles some pretty huge stuff.
  11. You might be able to just optimize your Python: .../PythonSpeed/PerformanceTips
  12. You may also be able to just select a better algorithm and/or datastructures, especially if you're using lots of nested loops.
  13. Numba - a JIT for CPython
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.


381

Back to Dan's tech tidbits

You can e-mail the author with questions or comments: