It's copy-pasted in the original mail and it's in the docs. Anyway,On Tue, Feb 26, 2013 at 7:07 PM, Eli Bendersky <email@example.com> wrote:
> On Tue, Feb 26, 2013 at 8:39 AM, Maciej Fijalkowski <firstname.lastname@example.org>
>> On Tue, Feb 26, 2013 at 6:34 PM, Eli Bendersky <email@example.com> wrote:
>> > On Tue, Feb 26, 2013 at 7:42 AM, Nick Coghlan <firstname.lastname@example.org>
>> > wrote:
>> >> On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski <email@example.com>
>> >> wrote:
>> >> > Hello.
>> >> >
>> >> > I would like to discuss on the language summit a potential inclusion
>> >> > of cffi 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 ;-)
this is just to familizarize people with the library. We're going to
discuss it on the language summit at pycon.
Python-Dev mailing list