[Python-Dev] cffi in stdlib

Maciej Fijalkowski fijall at gmail.com
Wed Feb 27 10:00:10 CET 2013

On Wed, Feb 27, 2013 at 6:53 AM, Eli Bendersky <eliben at gmail.com> wrote:
> * Work either at the level of the ABI (Application Binary Interface)
>> or the API (Application Programming Interface). Usually, C libraries
>> have a specified C API but often not an ABI (e.g. they may document a
>> “struct” as having at least these fields, but maybe more). (ctypes
>> works at the ABI level, whereas Cython and native C extensions work at
>> the API level.)
> I read the cffi docs once again and went through some of the examples. I
> want to divide this to two topics.
> One is what you call the "ABI" level. IMHO, it's hands down superior to
> ctypes. Your readdir demo demonstrates this very nicely. I would definitely
> want to see this in the stdlib as an alternative way to interface to C
> shared objects & DLLs.
> Two is what you call the "API" level, which is where my opinion becomes
> mixed. Some things just don't feel right to me:
> 1. Tying in a C compiler into the flow of a program. I'm not sure whether we
> have precedents for it in the stdlib. Does this work on Windows where
> libraries and DLLs are usually built with MSVC?

Yes. Precedent in the stdlib is really the C API. All the same rules
apply (including build and ship a dll).

> 2. Using a function called "verify" to create stuff. This may sound like a
> naming bikeshed, but it's not. It ties in to the question - why is this
> needed?

We welcome a better opinion of name (indeed verify is not that great).
This elevates ABI to API so either invokes the C compiler or reads
stuff from the cache.

> 3. The partial type specifications in C with ellipsis. What is the point?
> You have the C declarations somewhere anyhow, so why introduce this? The
> "ABI level" boasts having just C and Python to write, but those partial
> ellipsis-ridden declarations are hardly C.

No, you don't. Some libraries contain macros for example (like
OpenSSL) where you just can't use ABI because it makes no sense. It's
less common on windows where binary compatibility is important,
however looking on linux, multiple stdlib declaration would use
ellipsis in the man page. I can't seem to find one right now, but it's
something like:

struct X {
   int public_field;

which is impossible to do correctly with ctypes without exposing some
sort of platform dependency that might change without warning.

Another usages are #define SQLITE_OK ... which you don't know at the
time of writing (people assume those won't change and the do change).

> Please see this as constructive criticism, and I fully admit that I may not
> have went deep enough to see the big benefits of the "API" level that would
> justify all that complexity.

Sure. It might sound strange, but on linux (or posix in general)
binary compatibility is not a thing, so you need to do stuff to
account for that.

More information about the Python-Dev mailing list