[Python-Dev] libffi embedded in CPython
Wes Turner
wes.turner at gmail.com
Wed Mar 11 19:31:23 CET 2015
On Mar 11, 2015 12:55 PM, "Maciej Fijalkowski" <fijall at gmail.com> wrote:
>
> On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou <solipsis at pitrou.net>
wrote:
> > 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.
>
> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150311/41567522/attachment-0001.html>
More information about the Python-Dev
mailing list