On Mar 11, 2015 12:55 PM, "Maciej Fijalkowski" fijall@gmail.com wrote:
On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou solipsis@pitrou.net
wrote:
On Wed, 11 Mar 2015 17:27:58 +0000 Brett Cannon brett@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.
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)
Are there tests for this?
I'm going to propose a somewhat controversial idea: let's deprecate the ctypes module.
This is gratuitous.
I'm +1 on deprecating ctypes
-1. These docs are helpful for understanding the pros and cons of different CPython <-> C interfaces.
https://scipy-lectures.github.io/advanced/interfacing_with_c/interfacing_wit...
(https://github.com/scipy-lectures/scipy-lecture-notes/issues/131 discusses documenting CFFI here as well)