On Tue, Feb 26, 2013 at 5:34 PM, Davide Del Vento <ddvento@ucar.edu> wrote:
Well, not so fast :-) I'm glad you posted it here since I don't follow python-dev (too many mailing lists) and I'm happy to hear about this proposal, even if there isn't much to discuss about it from the pypy side.
There is not much more than I described in the mail "put it in" :)
Cheers. Davide Del Vento,
On 02/26/2013 08:13 AM, Maciej Fijalkowski wrote:
Eh, I'm a moron, this was supposed to go to python-dev, not here. please ignore
On Tue, Feb 26, 2013 at 5:11 PM, Maciej Fijalkowski <fijall@gmail.com> 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 * cairo-cffi * pyzmq * 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
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev