On Wed, 11 Mar 2015 17:27:58 +0000 Brett Cannon <brett at python.org> 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. > I'm going to propose a somewhat controversial idea: let's deprecate the > ctypes module. This is gratuitous. > 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. > All of this seems to match the > reasons we added ctypes in the first place while also being safer to use > than ctypes. 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. Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4