[Python-Dev] cffi in stdlib

[Maciej Fijalkowski]

On Tue, Feb 26, 2013 at 7:07 PM, Eli Bendersky <eliben at gmail.com> wrote:
>
>
>
> On Tue, Feb 26, 2013 at 8: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.
>
>
> Yep, I can think of some reasons too. But just mentioning it so you remember
> explicitly listing the advantages when it comes to writing a PEP or some
> other sort of formal proposal. An FWIW, I think there's already enough
> positive feedback to at least start drafting a PEP. It can always be
> rejected later ;-)
>
> Eli
>

It's copy-pasted in the original mail and it's in the docs. Anyway,
this is just to familizarize people with the library. We're going to
discuss it on the language summit at pycon.