[Python-Dev] libffi embedded in CPython

[Maciej Fijalkowski]

On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Wed, 11 Mar 2015 17:27:58 +0000
> Brett Cannon <brett at python.org> wrote:
>>
>> 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.
>
> Depends what you call "dangerous". C code doesn't rot quicker than pure
> Python code :-) Also, libffi really offers a wrapper around platform
> ABIs, which rarely change.

And yet, lesser known ABIs in libffi contain bugs (as we discovered
trying to work there with anything else than x86 really). Also there
*are* ABI differencies that change slowly over time (e.g. requiring
stack to be 16 byte aligned)

>
>> I'm going to propose a somewhat controversial idea: let's deprecate the
>> ctypes module.
>
> This is gratuitous.

I'm +1 on deprecating ctypes

>
>> 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.
>
> But they are not ctypes. For example, cffi wouldn't be obvious to use
> for interfacing with non-C code, since it requires you to write C-like
> declarations.

You mean like Fortran? Or what precisely?

> I don't understand why cffi would be safer than ctypes. At least not in
> the operation mode where it doesn't need to invoke a C compiler.
> Cython is a completely different beast, it requires a separate
> compilation pass which makes it useless in some situations.
>

Our main motivation for "safer" is "comes with less magic and less
gotchas", which also means "does less stuff". It's also smaller.