[pypy-dev] cffi in stdlib

[Maciej Fijalkowski]

On Tue, Feb 26, 2013 at 5:34 PM, Davide Del Vento <ddvento at 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 at 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 at python.org
>> http://mail.python.org/mailman/listinfo/pypy-dev
>>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev