On Tue, May 15, 2012 at 9:22 PM, <exar...@twistedmatrix.com> wrote: > On 03:11 pm, pypy-dev-requ...@python.org wrote: > >> >> Hi all, >> >> Fijal and me would like to raise interest among various groups of >> people about building a better ctypes replacement for Python. >> >> The general background first, at least as far as we know it. People >> generally agree that CPython extension modules are not extremely hard >> to write, but also not the ultimate solution in the matter of >> interfacing with C code. Obviously you need to know and write C code, >> and learn the large CPython C API. Moreover a CPython extension >> module is rather specific to CPython or even a particular version of >> it. Even if you are lucky and your CPython extensions work on all 2.x >> versions, it won't work unmodified on Python 3.x, and be slow (or not >> work at all) on PyPy. (I'm leaving Jython and IronPython out of the >> picture here but it's very far from ideal for them too.) >> >> The working alternatives nowadays are Cython and ctypes. For Cython >> you have to learn a whole new language; we can argue infinitely about >> preferences, but from my point of view it's mostly just a nicer way to >> write CPython C extensions using --- instead of C --- a custom >> language. About ctypes, I would say that the fact that its use >> remains marginal is enough to show that its mission kind of failed. >> Its problems are more than one, but most importantly the level at >> which you describe the information is slightly too low - it's >> ABI-level instead of API-level. It does not make a difference for some >> libraries, but for some it does make a huge difference, like when you >> use macros. We would like something that can be potentially used to >> wrap almost all C libraries. >> >> So we would like to propose something (a bit more publically than the >> two subprojects of PyPy attempting to do that --- did you know about >> their existence?). The goal would be to come up with a >> better-designed project. "Better designed" in my vocabulary implies >> "simpler". I'm starting in this mailing list but the idea is to try >> to move it in its own project, and to develop at the same time at >> least a CPython 2.7 and 3.x and PyPy implementation. >> >> The simplest FFI we know of for a high-level language is LuaJIT's FFI. >> If you are interested, read the four pages starting at >> http://luajit.org/ext_ffi.html . A crucial design decision was to >> avoid making use of tons of objects representing the C types; instead, >> the user mostly specifies C types as plain strings, simplifying the >> basic API a lot. >> > > Hi Armin, > > I don't think it's true that using strings instead of types (or other rich > objects) simplifies anything. Quite the opposite, it takes all of the > complexity which must exist and throws a huge wall up to prevent anyone > from understanding it without undertaking a huge amount of extra work. > > C is C, whether you hide the representation of its structure in a string > or whether you expose that representation as objects with useful, easy to > use APIs. > > Jean-Paul > ______________________________**_________________ > pypy-dev mailing list > pypy-dev@python.org > http://mail.python.org/**mailman/listinfo/pypy-dev<http://mail.python.org/mailman/listinfo/pypy-dev> >
The point is that using strings you can use (a subset of) C syntax. That means that you need to learn only one (and limitations) and not two ways to express stuff. I guess. Cheers, fijal
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev