[Python-Dev] cffi in stdlib

[Nick Coghlan]

On Wed, Feb 27, 2013 at 2:39 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> On Tue, Feb 26, 2013 at 6:34 PM, Eli Bendersky <eliben at gmail.com> wrote:
>>
>> On Tue, Feb 26, 2013 at 7:42 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>>
>>> On Wed, Feb 27, 2013 at 1:13 AM, 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.
>>>
>>> I think cffi is well worth considering as a possible inclusion for
>>> Python 3.4. (In particular, I'm a fan of the fact it just uses C
>>> syntax to declare what you're trying to talk to)
>>
>>
>> I'm cautiously +0.5 because I'd really like to see a strong comparison case
>> being made vs. ctypes. I've used ctypes many times and it was easy and
>> effortless (well, except the segfaults when wrong argument types are
>> declared :-). I'll be really interesting in seeing concrete examples that
>> demonstrate how CFFI is superior.
>
> My main issue with ctypes, other than confusing API, which is up to
> taste, is that you just cannot wrap some libraries, like OpenSSL
> because of API vs ABI. OpenSSL uses macros extensively. Another point
> is that even C POSIX stdlib gives you incomplete structs and you have
> to guess where to put what fields.

For me, it's mostly the fact that ctypes is *less* typesafe than C
itself, because you can't easily consume the header files directly,
which leads directly to the segfaults caused by wrong declarations.
While at the time of inclusion there was a solid "practicality beats
purity" case for adding ctypes (and it's taken us quite a long way),
being less typesafe than C is still quite an achievement :)

As an experienced C programmer, not having to learn a new hybrid
language for declarations is also a plus, but the "significantly less
likely to segfault" aspect is the big one.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia