* 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?

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?

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.

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.

Eli