[Python-Dev] Language Summit notes

[Ryan Gonzalez]

On Thu, Apr 10, 2014 at 3:12 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 10 April 2014 20:30, Antoine Pitrou <solipsis at 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 at 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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140410/10a12b2d/attachment.html>