On Thu, Dec 18, 2014, at 15:36, Jim J. Jewett 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?
>> [And why a fork, instead of just treating it as an external dependency]
>> Benjamin Peterson responded:
>> > It has some sort of Windows related patches. No one seems to know
> > whether they're still needed for newer libffi. Unfortunately, ctypes
> > doesn't currently have a maintainer.
>> Are any of the following false?
>> (1) Ideally, we would treat it as an external dependency.
>> (2) At one point, it was intentionally forked to get in needed
> patches, including at least some for 64 bit windows with MSVC.
>> (3) Upstream libffi maintenance has picked back up.
>> (4) Alas, that means the switch merge would not be trivial.
>> (5) In theory, we could now switch to the external version.
> [In particular, does libffi have a release policy such that we
> could assume the newest released version is "safe", so long as
> our integration doesn't break?]
>> (6) By its very nature, libffi changes are risky and undertested.
> At the moment, that is also true of its primary user, ctypes.
>> (7) So a switch is OK in theory, but someone has to do the
> non-trivial testing and merging, and agree to support both libffi
> and and ctypes in the future. Otherwise, stable wins.
>> (8) The need for future support makes this a bad candidate for
> "patches wanted"/"bug bounty"/GSoC.
Sounds about right.