[Python-Dev] libffi embedded in CPython

[Antoine Pitrou]

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.

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