[Python-Dev] libffi embedded in CPython

[Maciej Fijalkowski]

On Thu, Mar 12, 2015 at 12:20 AM, Brett Cannon <brett at python.org> wrote:
>
>
> On Wed, Mar 11, 2015 at 6:03 PM Paul Moore <p.f.moore at gmail.com> wrote:
>>
>> On 11 March 2015 at 21:45, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> >> Is it possible to use cffi without a C compiler/headers as easily than
>> >> ctypes?
>> >
>> > yes, it has two modes, one that does that and the other that does
>> > extra safety at the cost of a C compiler
>>
>> So if someone were to propose a practical approach to including cffi
>> into the stdlib, *and* assisting the many Windows projects using
>> ctypes for access to the Windows API [1], then there may be a
>> reasonable argument for deprecating ctypes. But nobody seems to be
>> doing that, rather the suggestion appears to be just to deprecate a
>> widely used part of the stdlib offering no migration path :-(
>
>
> You're ignoring that it's not maintained, which is the entire reason I
> brought this up. No one seems to want to touch the code. Who knows what
> improvements, bugfixes, etc. exist upstream in libffi that we lack because
> no one wants to go through and figure it out. If someone would come forward
> and help maintain it then I have no issue with it sticking around.

It's a bit worse than that. Each time someone wants to touch the code
(e.g. push back the upstream libffi fixes), there is "we need to
review it, but there is noone to do it", "noone knows how it works,
don't touch it" kind of feedback, which leads to disincentives to
potential maintainers. I would be likely willing to rip off the libffi
from CPython as it is for example (and just use the upstream one)