[Python-Dev] libffi embedded in CPython

[Maciej Fijalkowski]

On Wed, Mar 11, 2015 at 8:05 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Wed, 11 Mar 2015 19:54:58 +0200
> Maciej Fijalkowski <fijall at gmail.com> wrote:
>> >
>> > Depends what you call "dangerous". C code doesn't rot quicker than pure
>> > Python code :-) Also, libffi really offers a wrapper around platform
>> > ABIs, which rarely change.
>>
>> And yet, lesser known ABIs in libffi contain bugs (as we discovered
>> trying to work there with anything else than x86 really). Also there
>> *are* ABI differencies that change slowly over time (e.g. requiring
>> stack to be 16 byte aligned)
>
> Well, sure. The point is, such bugs are unlikely to appear at a fast
> rate... Also, I don't understand why libffi issues would affect cffi
> any less than it affects ctypes, at least in the compiler-less mode of
> operation.

My point here was only about shipping own libffi vs using the system
one (and it does affect cffi equally with or without compiler)

>
>> >> We now have things like cffi and Cython for people who need
>> >> to interface with C code. Both of those projects are maintained. And they
>> >> are not overly difficult to work with.
>> >
>> > But they are not ctypes. For example, cffi wouldn't be obvious to use
>> > for interfacing with non-C code, since it requires you to write C-like
>> > declarations.
>>
>> You mean like Fortran? Or what precisely?
>
> Any toolchain that can generate native code. It can be Fortran, but it
> can also be code generated at runtime without there being any external
> declaration. Having to generate "C declarations" for such code would be
> a distraction.
>
> Of course, if cffi gains the same ability as ctypes (namely to lookup
> a function and declare its signature without going through the
> FFI.cdef() interface), that issue disappears.
>
> As a side note, ctypes has a large number of users, so even if it were
> deprecated that wouldn't be a good reason to stop maintaining it.
>
> And calling cffi "simple" while it relies on a parser of the C language
> (which would then have to be bundled with Python) is a bit misleading
> IMO.
>
> Regards
>
> Antoine.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com