Re: [Python-Dev] libffi embedded in CPython
On Thu, Dec 18, 2014 at 10:36 PM, 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. > > -jJ I would like to add that "not doing anything" is not a good strategy either, because you accumulate bugs that get fixed upstream (I'm pretty sure all the problems from cpython got fixed in upstream libffi, but not all libffi fixes made it to cpython). ___ 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
Re: [Python-Dev] libffi embedded in CPython
On 19 December 2014 at 08:26, Maciej Fijalkowski wrote: > I would like to add that "not doing anything" is not a good strategy > either, because you accumulate bugs that get fixed upstream (I'm > pretty sure all the problems from cpython got fixed in upstream > libffi, but not all libffi fixes made it to cpython). Probably the easiest way of moving this forward would be for someone to identify the CPython-specific patches in the current version, and check if they are addressed in the latest libffi version. They haven't been applied as they are, I gather, but maybe equivalent fixes have been made. I've no idea how easy that would be (presumably not trivial, or someone would already have done it). If the patches aren't needed any more, upgrading becomes a lot more plausible. Paul ___ 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
Re: [Python-Dev] libffi embedded in CPython
On 19.12.2014 10:52, Paul Moore wrote: > Probably the easiest way of moving this forward would be for someone > to identify the CPython-specific patches in the current version, and > check if they are addressed in the latest libffi version. They haven't > been applied as they are, I gather, but maybe equivalent fixes have > been made. I've no idea how easy that would be (presumably not > trivial, or someone would already have done it). If the patches aren't > needed any more, upgrading becomes a lot more plausible. That's easy. All patches are tracked in the diff file https://hg.python.org/cpython/file/3de678cd184d/Modules/_ctypes/libffi.diff . The file *should* be up to date. Christian ___ 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
Re: [Python-Dev] libffi embedded in CPython
On Fri, 19 Dec 2014 09:52:26 + Paul Moore wrote: > On 19 December 2014 at 08:26, Maciej Fijalkowski wrote: > > I would like to add that "not doing anything" is not a good strategy > > either, because you accumulate bugs that get fixed upstream (I'm > > pretty sure all the problems from cpython got fixed in upstream > > libffi, but not all libffi fixes made it to cpython). > > Probably the easiest way of moving this forward would be for someone > to identify the CPython-specific patches in the current version, and > check if they are addressed in the latest libffi version. They haven't > been applied as they are, I gather, but maybe equivalent fixes have > been made. I've no idea how easy that would be (presumably not > trivial, or someone would already have done it). If the patches aren't > needed any more, upgrading becomes a lot more plausible. Another strategy is to dump our private fork, link with upstream instead, and see what breaks. Presumably, our test suite should be able to catch some (most?) of that breakage. Regards Antoine. ___ 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
Re: [Python-Dev] libffi embedded in CPython
On 19 December 2014 at 23:01, Antoine Pitrou wrote: > On Fri, 19 Dec 2014 09:52:26 + > Paul Moore wrote: > > On 19 December 2014 at 08:26, Maciej Fijalkowski > wrote: > > > I would like to add that "not doing anything" is not a good strategy > > > either, because you accumulate bugs that get fixed upstream (I'm > > > pretty sure all the problems from cpython got fixed in upstream > > > libffi, but not all libffi fixes made it to cpython). > > > > Probably the easiest way of moving this forward would be for someone > > to identify the CPython-specific patches in the current version, and > > check if they are addressed in the latest libffi version. They haven't > > been applied as they are, I gather, but maybe equivalent fixes have > > been made. I've no idea how easy that would be (presumably not > > trivial, or someone would already have done it). If the patches aren't > > needed any more, upgrading becomes a lot more plausible. > > Another strategy is to dump our private fork, link with upstream > instead, and see what breaks. > Presumably, our test suite should be able to catch some (most?) of that > breakage. > And if we're going to do something like that for 3.5, now's the time, since we still have a lot of lead time on the 3.5 release. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2014-12-12 - 2014-12-19)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4683 (+17)
closed 30168 (+31)
total 34851 (+48)
Open issues with patches: 2192
Issues opened (34)
==
#23042: Python 2.7.9 ctypes module doesn't build on FreeBSD x86
http://bugs.python.org/issue23042 opened by lemburg
#23043: doctest ignores "from __future__ import print_function"
http://bugs.python.org/issue23043 opened by fva
#23046: asyncio.BaseEventLoop is documented, but only exported via asy
http://bugs.python.org/issue23046 opened by vadmium
#23050: Add Japanese legacy encodings
http://bugs.python.org/issue23050 opened by t2y
#23051: multiprocessing.pool methods imap() and imap_unordered() cause
http://bugs.python.org/issue23051 opened by advance512
#23054: ConnectionError: ('Connection aborted.', BadStatusLine("""
http://bugs.python.org/issue23054 opened by joecabrera
#23055: PyUnicode_FromFormatV crasher
http://bugs.python.org/issue23055 opened by gvanrossum
#23056: tarfile raises an exception when reading an empty tar in strea
http://bugs.python.org/issue23056 opened by gregory.p.smith
#23057: asyncio loop on Windows should stop on keyboard interrupt
http://bugs.python.org/issue23057 opened by asvetlov
#23058: argparse silently ignores arguments
http://bugs.python.org/issue23058 opened by remram
#23059: cmd module should sort misc help topics
http://bugs.python.org/issue23059 opened by samwyse
#23060: Assert fails in multiprocessing.heap.Arena.__setstate__ on Win
http://bugs.python.org/issue23060 opened by steve.dower
#23061: Update pep8 to specify explicitly 'module level' imports at to
http://bugs.python.org/issue23061 opened by IanLee1521
#23062: test_argparse --version test cases
http://bugs.python.org/issue23062 opened by vadmium
#23063: `python setup.py check --restructuredtext --strict --metadata`
http://bugs.python.org/issue23063 opened by Marc.Abramowitz
#23065: Pyhton27.dll at SysWOW64 not updated when updating Python 2.7.
http://bugs.python.org/issue23065 opened by GamesGamble
#23067: Export readline forced_update_display
http://bugs.python.org/issue23067 opened by dexteradeus
#23068: Add a way to determine if the current thread has the import lo
http://bugs.python.org/issue23068 opened by gvanrossum
#23069: IDLE's F5 Run Module doesn't transfer effects of future import
http://bugs.python.org/issue23069 opened by rhettinger
#23071: codecs.__all__ incomplete
http://bugs.python.org/issue23071 opened by vadmium
#23072: 2.7.9 multiprocessing compile conflict
http://bugs.python.org/issue23072 opened by a...@purdue.edu
#23075: Mock backport in 2.7 relies on implementation defined behavior
http://bugs.python.org/issue23075 opened by alex
#23076: list(pathlib.Path().glob("")) fails with IndexError
http://bugs.python.org/issue23076 opened by Antony.Lee
#23077: PEP 1: Allow Provisional status for PEPs
http://bugs.python.org/issue23077 opened by ncoghlan
#23078: unittest.mock patch autospec doesn't work on staticmethods
http://bugs.python.org/issue23078 opened by kevinbenton
#23079: os.path.normcase documentation confusing
http://bugs.python.org/issue23079 opened by chris.jerdonek
#23080: BoundArguments.arguments should be unordered
http://bugs.python.org/issue23080 opened by Antony.Lee
#23081: Document PySequence_List(o) as equivalent to list(o)
http://bugs.python.org/issue23081 opened by larsmans
#23082: pathlib relative_to() can give confusing error message
http://bugs.python.org/issue23082 opened by chris.jerdonek
#23085: update internal libffi copy to 3.2.1
http://bugs.python.org/issue23085 opened by gustavotemple
#23086: Add start and stop parameters to the Sequence.index() ABC mixi
http://bugs.python.org/issue23086 opened by rhettinger
#23087: Exec variable not found error
http://bugs.python.org/issue23087 opened by Keith.Chewning
#23088: Document that PyUnicode_AsUTF8() returns a null-terminated str
http://bugs.python.org/issue23088 opened by vadmium
#23089: Update libffi config files
http://bugs.python.org/issue23089 opened by gustavotemple
Most recent 15 issues with no replies (15)
==
#23088: Document that PyUnicode_AsUTF8() returns a null-terminated str
http://bugs.python.org/issue23088
#23087: Exec variable not found error
http://bugs.python.org/issue23087
#23086: Add start and stop parameters to the Sequence.index() ABC mixi
http://bugs.python.org/issue23086
#23081: Document PySequence_List(o) as equivalent to list(o)
http://bugs.python.org/issue23081
#23078: unittest.mock patch autospec doesn't work on staticmethods
http://bugs.python.org/issue23078
#23077: PEP 1: Allow Provisional status for PEPs
http://bugs.python.org/issue23077
#23075: Mock backport in 2.7 relies on implementation defined behavior
http://bugs.p
