On Wed, Feb 27, 2013 at 11:18 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote: > > On 27 Feb, 2013, at 10:06, Maciej Fijalkowski <fijall at gmail.com> wrote: > >> On Wed, Feb 27, 2013 at 9:29 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote: >>> >>> 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. >> >> 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).
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