<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 3 Mar 2016 at 10:04 Antoine Pitrou <<a href="mailto:antoine@python.org">antoine@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Le 03/03/2016 18:58, Eric Snow a écrit :<br>
>> It is doing fine as an external library, but if something as radical as<br>
>> heavily trimming back and/or rewriting the C API occurs then having CFFI in<br>
>> the stdlib to evolve with the internal C changes makes sense. I think that's<br>
>> where the thought of pulling CFFI in the stdlib stems from.<br>
><br>
> At least part of the motivation was to deprecate/remove ctypes and<br>
> replace it in the stdlib with CFFI.<br>
<br>
Why would that be desirable again? ctypes works perfectly fine and cffi<br>
isn't better for its core use case (runtime binding of C libraries).<br></blockquote><div><br></div><div>Ignoring the potential to crash the interpreter (I personally don't care but some do), is the maintenance issue we have with ctypes (or at least that's my hang-up with it). I think we still have not figured out what code we have patched and so no one has been willing to update to a newer version of libffi. I think Zachary looked into it and got some distance but never far enough to feel comfortable with trying to update things.</div><div><br></div><div>But I thought CFFI's ABI in-line solution matched what ctypes did?</div></div></div>