[pypy-dev] Python FFI

[Stefan Behnel]

Armin Rigo, 15.05.2012 18:34:
> On Tue, May 15, 2012 at 5:56 PM, Yury Selivanov wrote:
>> While I don't like some design quirks of Cython, I think that it's far
>> better than any ffi or ctypes-like solution.  Essentially, it's an ffi
>> merged with the language, not a separate module.  And that's a pretty
>> unique approach.  Why not focus on improving Cython design and moving
>> toward some superset of Python language, that every implementation
>> should support natively?
> 
> I'm quite sure it will never happen.  See for example the new section
> "Pure Python Mode" in http://docs.cython.org/src/tutorial/pure.html:
> it is again about adding ffi-like glue to Python files.  It is a
> reasonable next step in the Cython project, but it shows precisely
> that there is no chance to add all of Cython into the Python language
> definition.
> 
> If I got you correctly, such ffi-like glue code is the part that you
> dislike.  I agree with you, but I don't think we can hope for a
> solution with no glue at all; instead, we can try to minimize it as
> much as possible.  I may be wrong, but until proven otherwise, I am
> under the impression that LuaJIT's approach leads to significantly
> less glue code than Cython's Pure Python Mode.  (This is true even
> though the former is complete and the latter so far not: from the
> Cython docs, "A limited attempt is made to emulate these more complex
> types, but only so much can be done from the Python language.")

I dislike the idea of having yet another way of declaring external C APIs,
though. Basically, all that's really lacking in Cython's pure Python mode
is the ability to talk to C code, simply because that currently can't work
from uncompiled Python code. If there was a way to build a ctypes-like
thing on top of Cython's declarations, that could also be used to improve
Cython's pure mode, in addition to becoming the preferred way of doing C
code interaction in JIT compiled Pythons.

Stefan