On Thu, 3 Mar 2016 at 10:04 Antoine Pitrou <anto...@python.org> wrote:
> > 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?
_______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
