[Python-Dev] libffi embedded in CPython

Brett Cannon brett at python.org
Wed Mar 11 18:27:58 CET 2015

On Mon, Dec 22, 2014 at 4:49 PM Jim J. Jewett <jimjjewett at 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150311/6abb413f/attachment.html>

More information about the Python-Dev mailing list