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