On Wed, Feb 27, 2013 at 5:57 PM, Eli Bendersky <eli...@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?
the general goal is to provide alternative for writing C API by hand
(so SWIG, ctypes, cython, whatever).
>
>>
>>
>> > 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.
>
>
> Can you elaborate on what "elevates ABI to API" means here?
>
>>
>> > 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.
>
>
> It would be useful to find an actual example and discuss it concretely.
#define Py_INCREF(x) (x -> refcnt++)
the API here is Py_INCREF, which is a macro and does not exist in the
DLL. copy-pasting the implementation is not using the API, it's hoping
that stuff won't change in the future (and say makes it not working
when PyPy implements Py_INCREF as a function). Some POSIX things are
macros in one version of glibc and functions in other and there is no
change in API so your code will silently stop working.
>
>>
>> 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).
>
>
> Do you mean that the value of SQLITE_OK changed over time (now it's 0, but
> used to be different?)
>
> If so, then in a realistic use case, how would the API level help solve
> this?
>
> Eli
no the API is SQLITE_OK. The actual numeric value of 0 is *not* part
of the API. it might be 0 it might be not, you never know. In cffi you
write:
#define SQLITE_OK ...
and let the compiler figure out. in ctypes you just hardcode 0. I
ended up once with a scary mess of ifs because BSD Linux and OS X were
declaring the same numeric constants with different values.
_______________________________________________
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
