On Wed, Feb 27, 2013 at 11:18 AM, Ronald Oussoren <ronaldousso...@mac.com> wrote: > > On 27 Feb, 2013, at 10:06, Maciej Fijalkowski <fij...@gmail.com> wrote: > >> On Wed, Feb 27, 2013 at 9:29 AM, Ronald Oussoren <ronaldousso...@mac.com> >> wrote: >>> >>> On 26 Feb, 2013, at 16:13, Maciej Fijalkowski <fij...@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. >> >> 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.
I implemented ctypes. It is. >>> 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? >> >> no idea. > > 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. > > Ronald if cpython supports it and you can load it using dlopen, it does work then (it really is just building a C extension on the API level). _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
