On Mar 11, 2015 12:55 PM, "Maciej Fijalkowski" <fij...@gmail.com> wrote: > > On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > > On Wed, 11 Mar 2015 17:27:58 +0000 > > Brett Cannon <br...@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_with_c.html (https://github.com/scipy-lectures/scipy-lecture-notes/issues/131 discusses documenting CFFI here as well)
_______________________________________________ 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
