[Python-ideas] discouraging direct use of the C-API

[Paul Moore]

On 6 May 2015 at 17:41, Guido van Rossum <guido at python.org> wrote:
> As for CFFI, is the ownership/maintenance issue solved yet? IIRC we have
> some really outdated versions in the CPython tree and nobody wants to step
> in and upgrade these to the latest CFFI, for some reason (such as that that
> would actually break a lot of code because the latest version is so
> different from the version we currently include?).

I think you are referring to libffi (used by ctypes) here rather than cffi.

Libffi isn't really relevant to the original topic, but the big issue
there is that ctypes on Windows uses a patched copy of a pretty old
version of libffi. The reason it does is to trap stack usage errors so
that it can give a ValueError if you call a C function with the wrong
number of arguments. libffi doesn't offer a way to do this, so
migrating to the latest libffi would mean hacking out that code, and a
loss of the stack checking (which is currently tested for, so although
it's not exactly an API guarantee, it would be a compatibility break).

Otherwise, it's mostly a matter of getting the build steps to work.
Zach Ware got 32-bit builds going, and his approach (use git bash to
run configure and keep a copy of the results) should in principle be
fine for 64-bit, but I stalled because I've no way of testing a libffi
build short of building the whole of Python and running the ctypes
tests, which is both heavy handed and likely to obscure the root cause
of any actual bugs found that way :-(

The big problem is that ctypes with the current embedded libffi is
"good enough" on Windows, which is where the bulk of ctypes usage
occurs. So there's no compelling reason to put in the work to upgrade
it. And (as usual) few people with the necessary expertise (in this
case, Windows, C, Unix-style build processes, and assembler-level
calling conventions - a pretty impressive mix!).

Paul