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 wrote:
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:
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 ;-)
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.