[Python-Dev] cffi in stdlib

[Donald Stufft]

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:

> Hello.
>  
> 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
> ctypes:
>  
> * 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
> functions).
>  
> * 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
> Python.
>  
> 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.
>  
> Cheers,
> fijal
>  
> .. [1]: http://cffi.readthedocs.org/en/release-0.5/
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org (mailto:Python-Dev at python.org)
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130226/5345f89e/attachment.html>