On Thu, 3 Mar 2016 at 10:04 Antoine Pitrou <antoine@python.org> wrote:
It is doing fine as an external library, but if something as radical as heavily trimming back and/or rewriting the C API occurs then having CFFI in the stdlib to evolve with the internal C changes makes sense. I think
Le 03/03/2016 18:58, Eric Snow a écrit : that's
where the thought of pulling CFFI in the stdlib stems from.
At least part of the motivation was to deprecate/remove ctypes and replace it in the stdlib with CFFI.
Why would that be desirable again? ctypes works perfectly fine and cffi isn't better for its core use case (runtime binding of C libraries).
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.
But I thought CFFI's ABI in-line solution matched what ctypes did?