Le 03/03/2016 18:58, Eric Snow a écrit :
>> 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 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?