On Thu, Apr 10, 2014 at 3:12 PM, Paul Moore <p.f.mo...@gmail.com> wrote:
> On 10 April 2014 20:30, Antoine Pitrou <solip...@pitrou.net> wrote: > > FWIW, I do hope there would be a PEP before including CFFI... Actually I > > don't understand what would justify an exemption. > > I agree. I'd like to see a clear explanation of what advantages (and > disadvantages!) CFFI gives over ctypes, as well as the plan for > inclusion and how the inevitable confusion over whether to use ctypes > or cffi will be handled. The fact that cffi requires bringing in ply > and a vendored-but-not-public copy of pycparser, seems to imply to me > that there's a lot of cost and I'd like to understand the gains. > That's not to say that adding ply to the standard library mightn't be > worth it in its own right, but there are a lot of other parsers out > there, and I'd rather we blessed one as "best of breed" rather than > "because cffi uses it". > > In particular, my understanding is that in order to get the key > benefits of cffi (API compatibility rather than ABI) you need to > include some sort of complex "generate and compile C" step in your > project's build. That implies that using cffi requires building > separate wheels for each Python version (as with any C extension) and > having a C compiler to do the build. There are a lot of projects that > I know of (particularly wrappers for Windows APIs like Colorama and > pyreadline) migrating to ctypes precisely because they get a pure > Python solution that doesn't need binary builds or version-dependent > distributions. Those projects won't presumably be migrating to cffi. > Also, a key area where ctypes is used seems to be the Windows API - > and there, ABI compatibility for Windows APIs is the norm so the > advantage of only needing API compatibility is minimal at best. > Nope. CFFI supports both C-built extensions and ctypes-style shared library loading. There are pure-Python bindings for modules that use CFFI and don't require a C compiler(https://github.com/kirbyfan64/clamav-python). > At the moment, I see no real reason to add cffi to the stdlib - it > certainly isn't an "obvious" decision to do so. This seems like clear > PEP territory. It's somewhat faster but has a longer warm-up time. Useful if the same module is going to be reused several times. > > 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/rymg19%40gmail.com > -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."
_______________________________________________ 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
