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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
