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
