On Wed, Feb 27, 2013 at 7:57 AM, Eli Bendersky <eliben@gmail.com> wrote:

> 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).

So would you say that the main use of the API level is provide an alternative for writing C API code to interface to C libraries. IOW, it's in competition with Swig?

I'd hardly call it competition. The primary language I interface with is C++ and cffi appears not see that giant elephant in the room (it'd need to use clang for parsing if it were going to do that)...

The goal is good, but being C only isn't super exciting to me.

Would there be a goal of using cffi to replace C extension module code in the standard library with cffi based versions instead of hand written CPython C API code?

If not, why not? (and what does that say about its limitations or practical it is?)

-0.5 from me. My inclination is not to add this to the standard library. But even if it were to be added, it sounds like others are coming up with questions and reasons why it isn't yet ready (always the first important step to seriously considering inclusion).

-gps