On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou
On Wed, 11 Mar 2015 17:27:58 +0000 Brett Cannon
wrote: Did anyone ever step forward to do this? I'm a bit worried about the long-term viability of ctypes if we don't have a maintainer or at least someone making sure we are staying up-to-date with upstream libffi. The ctypes module is a dangerous thing, so having a chunk of C code that isn't being properly maintained seems to me to make it even more dangerous.
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)
I'm going to propose a somewhat controversial idea: let's deprecate the ctypes module.
This is gratuitous.
I'm +1 on deprecating ctypes
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?
I don't understand why cffi would be safer than ctypes. At least not in the operation mode where it doesn't need to invoke a C compiler. Cython is a completely different beast, it requires a separate compilation pass which makes it useless in some situations.
Our main motivation for "safer" is "comes with less magic and less gotchas", which also means "does less stuff". It's also smaller.