On Mon, Dec 22, 2014 at 4:49 PM Jim J. Jewett <jimjjew...@gmail.com> wrote:
> > > On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote: > > ... http://bugs.python.org/issue23085 ... > > is there any reason any more for libffi being included in CPython? > > > Paul Moore wrote: > > Probably the easiest way of moving this forward would be for someone > > to identify the CPython-specific patches in the current version ... > > Christian Heimes wrote: > > That's easy. All patches are tracked in the diff file > > https://hg.python.org/cpython/file/3de678cd184d/Modules/_ > ctypes/libffi.diff > > That (200+ lines) doesn't seem to have all the C changes, such as the > win64 sizeof changes from issue 11835. > > Besides http://bugs.python.org/issue23085, there is at least > http://bugs.python.org/issue22733 > http://bugs.python.org/issue20160 > http://bugs.python.org/issue11835 > > which sort of drives home the point that making sure we have a > good merge isn't trivial, and this isn't an area where we should > just assume that tests will catch everything. I don't think it > is just a quicky waiting on permission. > > I've no doubt that upstream libffi is better in many ways, but > those are ways people have already learned to live with. > > That said, I haven't seen any objections in principle, except > perhaps from Steve Dower in the issues. (I *think* he was > just saying "not worth the time to me", but it was ambiguous.) > > I do believe that Christian or Maciej *could* sort things out well > enough; I have no insight into whether they have (or someone else > has) the time to actually do so. > Did anyone ever step forward to do this? I'm a bit worried about the long-term viability of ctypes if we don't have a maintainer or at least someone making sure we are staying up-to-date with upstream libffi. The ctypes module is a dangerous thing, so having a chunk of C code that isn't being properly maintained seems to me to make it even more dangerous. I'm going to propose a somewhat controversial idea: let's deprecate the ctypes module. We now have things like cffi and Cython for people who need to interface with C code. Both of those projects are maintained. And they are not overly difficult to work with. All of this seems to match the reasons we added ctypes in the first place while also being safer to use than ctypes. And I'm not saying we need to remove it in Python 3.6 or something. But I think it would be wise to deprecate the module to promote people to use third-party solutions to interfacing with C code and to eventually remove the maintenance burden at some point when we clear out all of our deprecated cruft (I call that Python 4, you can call it "some day way in the future" if you prefer).
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
