On 6/18/2012 5:29 PM, Armin Rigo wrote: > On Mon, Jun 18, 2012 at 9:10 PM, Maciej Fijalkowski <fijall at gmail.com> wrote: >> Me >>> Make cffi less buggy (check the tracker for new test cases ;-), faster >>> (closer to swig type wrappers), and easier to use than ctypes, and I am sure >>> there will be interest. >> >> I would say it's already fulfilling those three, but I suppose you should >> try for yourself. > I don't think the first is fulfilled so far, as we found various > issues on various Linux and non-Linux platforms (and fixed them, so I > suppose that release 0.1.1 is coming soon). But I agree with Fijal > about speed and ease of use. Like SWIG it generates wrappers in the > form of a CPython C extension with built-in functions, so I suppose > the performance is similar to SWIG and not ctypes. Well, SWIG > wrappers typically have custom logic written in C, whereas in cffi > this logic is typically written as Python code, so I suppose it ends > up being slower (on CPython; on PyPy small wrapping functions are > inlined and have little cost). But the same argument can be pushed > further to "why did you use a slow language like Python to write your > app in the first place", which I hope we agree is bogus :-) Yes, because languages have no speed, only implementations do; and yes, because when CPython really is too slow for a particular task, it can be pushed onto C. But some people (pygame, others on python-list) have reported that for their project, ctypes negates too much of the C speedup, relative to swig or similar. So it has not been quite the C wrapper generator killer that some people hoped for. (This is not to say that is not great for uses it does succeed at.) -- Terry Jan Reedy
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