A big +1 from me for cffi in the stdlib it's a great library.

I just recently started using it to make bindings to a C library. I
looked at the ctypes library, but haven't actually used it, because
the docs confused me but with cffi I was able to get somewhere just
by a liberal use of copy/paste from the C library's home page. The
only C I know I figured out from working with cffi and fwiw even with
that minimal amount of gained knowledge I still am confused by the
Ctypes docs and where to even really start to try to use it.

On Tuesday, February 26, 2013 at 10:13 AM, Maciej Fijalkowski wrote:


I would like to discuss on the language summit a potential inclusion
of cffi[1] into stdlib. This is a project Armin Rigo has been working
for a while, with some input from other developers. It seems that the
main reason why people would prefer ctypes over cffi these days is
"because it's included in stdlib", which is not generally the reason I
would like to hear. Our calls to not use C extensions and to use an
FFI instead has seen very limited success with ctypes and quite a lot
more since cffi got released. The API is fairly stable right now with
minor changes going in and it'll definitely stablize until Python 3.4
release. Notable projects using it:

* pypycore - gevent main loop ported to cffi
* pgsql2cffi
* sdl-cffi bindings
* tls-cffi bindings
* lxml-cffi port
* pyzmq
* cairo-cffi
* a bunch of others

So relatively a lot given that the project is not even a year old (it
got 0.1 release in June). As per documentation, the advantages over

* The goal is to call C code from Python. You should be able to do so
without learning a 3rd language: every alternative requires you to
learn their own language (Cython, SWIG) or API (ctypes). So we tried
to assume that you know Python and C and minimize the extra bits of
API that you need to learn.

* Keep all the Python-related logic in Python so that you don’t need
to write much C code (unlike CPython native C extensions).

* Work either at the level of the ABI (Application Binary Interface)
or the API (Application Programming Interface). Usually, C libraries
have a specified C API but often not an ABI (e.g. they may document a
“struct” as having at least these fields, but maybe more). (ctypes
works at the ABI level, whereas Cython and native C extensions work at
the API level.)

* We try to be complete. For now some C99 constructs are not
supported, but all C89 should be, including macros (and including
macro “abuses”, which you can manually wrap in saner-looking C

* We attempt to support both PyPy and CPython, with a reasonable path
for other Python implementations like IronPython and Jython.

* Note that this project is not about embedding executable C code in
Python, unlike Weave. This is about calling existing C libraries from

so among other things, making a cffi extension gives you the same
level of security as writing C (and unlike ctypes) and brings quite a
bit more flexibility (API vs ABI issue) that let's you wrap arbitrary
libraries, even those full of macros.


.. [1]: http://cffi.readthedocs.org/en/release-0.5/
Python-Dev mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com