On Tue, Feb 26, 2013 at 5:34 PM, Davide Del Vento <ddve...@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 <fij...@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 >>> >>> .. [1]: http://cffi.readthedocs.org/en/release-0.5/ >> >> _______________________________________________ >> 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 _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
