<p dir="ltr"><br>
On Mar 11, 2015 12:55 PM, "Maciej Fijalkowski" <<a href="mailto:fijall@gmail.com">fijall@gmail.com</a>> wrote:<br>
><br>
> On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
> > On Wed, 11 Mar 2015 17:27:58 +0000<br>
> > Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> >><br>
> >> Did anyone ever step forward to do this? I'm a bit worried about the<br>
> >> long-term viability of ctypes if we don't have a maintainer or at least<br>
> >> someone making sure we are staying up-to-date with upstream libffi. The<br>
> >> ctypes module is a dangerous thing, so having a chunk of C code that isn't<br>
> >> being properly maintained seems to me to make it even more dangerous.<br>
> ><br>
> > Depends what you call "dangerous". C code doesn't rot quicker than pure<br>
> > Python code :-) Also, libffi really offers a wrapper around platform<br>
> > ABIs, which rarely change.<br>
><br>
> And yet, lesser known ABIs in libffi contain bugs (as we discovered<br>
> trying to work there with anything else than x86 really). Also there<br>
> *are* ABI differencies that change slowly over time (e.g. requiring<br>
> stack to be 16 byte aligned)</p>
<p dir="ltr">Are there tests for this?</p>
<p dir="ltr">><br>
> ><br>
> >> I'm going to propose a somewhat controversial idea: let's deprecate the<br>
> >> ctypes module.<br>
> ><br>
> > This is gratuitous.<br>
><br>
> I'm +1 on deprecating ctypes</p>
<p dir="ltr">-1. These docs are helpful for understanding the pros and cons of different CPython <-> C interfaces.</p>
<p dir="ltr"><a href="https://scipy-lectures.github.io/advanced/interfacing_with_c/interfacing_with_c.html">https://scipy-lectures.github.io/advanced/interfacing_with_c/interfacing_with_c.html</a></p>
<p dir="ltr">(<a href="https://github.com/scipy-lectures/scipy-lecture-notes/issues/131">https://github.com/scipy-lectures/scipy-lecture-notes/issues/131</a> discusses documenting CFFI here as well)</p>