[Python-Dev] cffi in stdlib
Daniel Holth
dholth at gmail.com
Wed Feb 27 20:55:30 CET 2013
More information about the Python-Dev mailing list
Wed Feb 27 20:55:30 CET 2013
- Previous message: [Python-Dev] cffi in stdlib
- Next message: [Python-Dev] cffi in stdlib
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, Feb 27, 2013 at 4: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. 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.
- Previous message: [Python-Dev] cffi in stdlib
- Next message: [Python-Dev] cffi in stdlib
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list