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@python.org (mailto:Python-Dev@python.org) > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com > >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
