On Wed, 11 Mar 2015 19:54:58 +0200 Maciej Fijalkowski <fij...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
