On 27 Feb, 2013, at 10:06, Maciej Fijalkowski firstname.lastname@example.org wrote:
On Wed, Feb 27, 2013 at 9:29 AM, Ronald Oussoren email@example.com wrote:
On 26 Feb, 2013, at 16:13, Maciej Fijalkowski firstname.lastname@example.org wrote:
I would like to discuss on the language summit a potential inclusion of cffi into stdlib.
The API in general looks nice, but I do have some concens w.r.t. including cffi in the stdlib.
- 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.
Because ctypes API is a mess and magic. We needed a cleaner (and much smaller) model.
The major advantages of starting over is probably that you can hide the complexity and that opens opportunities for optimizations. That said, I'm not convinced that ctypes is unnecessarily complex.
- 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)
Yes. pycparser and ply.
Which aren't part of the stdlib right now.
- 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.
It seems to work.
That's not a confidency inspiring comment :-). That said, I use a hacked up fork of pycparser to parse Apple's Cocoa headers for PyObjC and it appears to work fine for that.
- 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?
That's somehting that will have to be resolved before cffi can be included in the stdlib, fat binaries are supported by CPython and are used the binary installers.