This document tries to explain how to interface the PyPy python interpreter with any external library.
Note: We try to describe state-of-the art, but it might fade out of date as this is the front on which things are changing in pypy rapidly.
Right now, there are three posibilities of providing third-party modules for the PyPy python interpreter (in order of usefulnes):
The ctypes module in PyPy is ready to use. It's goal is to be as-compatible-as-possible with the CPython ctypes version. Right now it's able to support large examples, such as pyglet. PyPy is planning to have a 100% compatible ctypes implementation, without the CPython C-level API bindings (so it is very unlikely that direct object-manipulation trickery through this API will work).
We also provide a ctypes-configure for overcoming the platform dependencies, not relying on the ctypes codegen. This tool works by querying gcc about platform-depenent details (compiling small snippets of C code and running them), so it'll benefit not pypy-related ctypes-based modules as well.
Stable, CPython-compatible API
Only pure-python code (slow), problems with platform-dependency (although we partially solve those). PyPy implementation is now very slow.
CPython ctypes: http://python.net/crew/theller/ctypes/
Mostly in order to be able to write a ctypes module, we developed a very low-level libffi bindings. (libffi is a C-level library for dynamic calling, which is used by CPython ctypes). This library provides stable and usable API, although it's API is a very low-level one. It does not contain any magic.
Works. Combines disadvantages of using ctypes with disadvantages of using mixed modules. Probably more suitable for a delicate code where ctypes magic goes in a way.
Slow. CPython-incompatible API, very rough and low-level
This is the most advanced and powerful way of writing extension modules. It has some serious disadvantages:
Some document is available here