[Python-Dev] Language Summit notes

[Paul Moore]

On 10 April 2014 20:30, Antoine Pitrou <solipsis at pitrou.net> wrote:
> FWIW, I do hope there would be a PEP before including CFFI... Actually I
> don't understand what would justify an exemption.

I agree. I'd like to see a clear explanation of what advantages (and
disadvantages!) CFFI gives over ctypes, as well as the plan for
inclusion and how the inevitable confusion over whether to use ctypes
or cffi will be handled. The fact that cffi requires bringing in ply
and a vendored-but-not-public copy of pycparser, seems to imply to me
that there's a lot of cost and I'd like to understand the gains.
That's not to say that adding ply to the standard library mightn't be
worth it in its own right, but there are a lot of other parsers out
there, and I'd rather we blessed one as "best of breed" rather than
"because cffi uses it".

In particular, my understanding is that in order to get the key
benefits of cffi (API compatibility rather than ABI) you need to
include some sort of complex "generate and compile C" step in your
project's build. That implies that using cffi requires building
separate wheels for each Python version (as with any C extension) and
having a C compiler to do the build. There are a lot of projects that
I know of (particularly wrappers for Windows APIs like Colorama and
pyreadline) migrating to ctypes precisely because they get a pure
Python solution that doesn't need binary builds or version-dependent
distributions. Those projects won't presumably be migrating to cffi.
Also, a key area where ctypes is used seems to be the Windows API -
and there, ABI compatibility for Windows APIs is the norm so the
advantage of only needing API compatibility is minimal at best.

At the moment, I see no real reason to add cffi to the stdlib - it
certainly isn't an "obvious" decision to do so. This seems like clear
PEP territory.

Paul