[Python-Dev] cffi in stdlib (original) (raw)

Ronald Oussoren ronaldoussoren at mac.com
Wed Feb 27 08:29:47 CET 2013

On 26 Feb, 2013, at 16:13, Maciej Fijalkowski <fijall at gmail.com> wrote:

Hello.

I would like to discuss on the language summit a potential inclusion of cffi[1] into stdlib.

The API in general looks nice, but I do have some concens w.r.t. including cffi in the stdlib.

  1. Why is cffi completely separate from ctypes, instead of layered on top of it? That is, add a utility module to ctypes that can parse C declarations and generate the right ctypes definitions.

  2. Cffi has a dependencies on pycparser and that module and its dependencies would therefore also be added to the stdlib (even if they'd be hidden in the cffi package)

  3. Cffi basicly contains a (limited) C parser, and those are notoriously hard to get exactly right. Luckily cffi only needs to interpret declarations and not the full language, but even so this can be a risk of subtle bugs.

  4. And finally a technical concern: how well does cffi work with fat binaries on OSX? In particular, will the distutils support generate cached data for all architectures supported by a fat binary?

Also, after playing around with it for 5 minutes I don't quite understand how to use it. Let's say I want to wrap a function "CGPoint CGPointMake(CGFloat x, CGFloat y)". Is is possible to avoid mentioning the exact typedef for CGFloat somewhere? I tried using:

ffi.cdef("typedef ... CGFloat; typedef struct { CGFloat x; CGFloat y; } CGPoint; CGPoint CGPointMake(CGFloat x, CGFloat y);")

But that results in an error when calling verify:

TypeError: field 'struct CGPoint.x′hasctype′structCGPoint.x' has ctype 'struct CGPoint.x′hasctype′structCGFloat' of unknown size

From a first glance this doesn't seem to buy me that much w.r.t. ctypes, I still have to declare the actual type of CGFloat which is documented as "some floating point type".

Ronald

More information about the Python-Dev mailing list