On Wed, Mar 11, 2015 at 8:05 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > 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.
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@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com _______________________________________________ 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