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

[Maciej Fijalkowski]

On Tue, May 15, 2012 at 9:22 PM, <exarkun at twistedmatrix.com> wrote:

> 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
> ______________________________**_________________
> pypy-dev mailing list
> pypy-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20120515/b60befda/attachment.html>