[pypy-dev] pypy-dev Digest, Vol 13, Issue 21

[exarkun at twistedmatrix.com]

On 03:11 pm, pypy-dev-request at 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