On Wed, Feb 27, 2013 at 2:39 AM, Maciej Fijalkowski <fij...@gmail.com> wrote: > On Tue, Feb 26, 2013 at 6:34 PM, Eli Bendersky <eli...@gmail.com> wrote: >> >> On Tue, Feb 26, 2013 at 7:42 AM, Nick Coghlan <ncogh...@gmail.com> wrote: >>> >>> On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski <fij...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com