On Wed, Feb 27, 2013 at 4: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.
cffi actually does have a ctypes backend in addition to the ffi and "compile a CPython extension" backends. But the ctypes backend is guaranteed to be slow and messy because it is ctypes. _______________________________________________ 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
