A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2013-February/124358.html below:

[Python-Dev] cffi in stdlib

[Python-Dev] cffi in stdlibPaul Moore p.f.moore at gmail.com
Tue Feb 26 19:14:26 CET 2013
On 26 February 2013 16:34, Eli Bendersky <eliben at gmail.com> wrote:
> I'm cautiously +0.5 because I'd really like to see a strong comparison case
> being made vs. ctypes. I've used ctypes many times and it was easy and
> effortless (well, except the segfaults when wrong argument types are
> declared :-). I'll be really interesting in seeing concrete examples that
> demonstrate how CFFI is superior.

I'm probably the same, mainly because I've successfully used ctypes in
the past, but I've never used cffi. That's something I need to
rectify.

One point which I *think* is correct, but which I don't see noted
anywhere. Am I right that cffi needs a C compiler involved in the
process, at least somewhere? If that's the case, then it is not a
suitable option for at least one use case that I have, writing quick
hacks involving the Windows API on a machine that doesn't have a C
compiler installed. Another possible case would be writing zip-safe
code - if cffi involves a compiled C extension, it won't work when
loaded from a zipfile.

In general, a proper, unbiased comparison between cffi and ctypes
would be useful.

BTW, I assume that the intention is that both cffi and ctypes remain
available indefinitely? Nobody's looking to deprecate ctypes?

Paul
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4