[pypy-dev] offtopic, ontopic, ...

[mark florisson]

On 14 February 2012 18:00, Maciej Fijalkowski <fijall at gmail.com> wrote:
> On Tue, Feb 14, 2012 at 7:56 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
>> Amaury Forgeot d'Arc, 14.02.2012 18:45:
>>> 2012/2/14 Stefan Behnel
>>>> if PyPy can't come up with a fast way to
>>>> interface with C code, it's bound to die.
>>>
>>> But it certainly can! For example PyPy implements the _ssl and pyexpat
>>> modules,
>>> which are interfaces to the openssl and expat libraries.
>>> And it does that by generating C code that calls the corresponding
>>> functions.
>>>
>>> See for example the code for SSLObject.write():
>>> https://bitbucket.org/pypy/pypy/src/default/pypy/module/_ssl/interp_ssl.py#cl-157
>>> it calls the C function SSL_write(), which is declared like this:
>>> https://bitbucket.org/pypy/pypy/src/default/pypy/rlib/ropenssl.py#cl-255
>>> This kind of code is not difficult to write (in this case, it's a simple
>>> translation of
>>> CPython modules) and is close enough to C when you really need it.
>>> For example, it's possible to use macros when they look like function calls,
>>> or embed C snippets.
>>
>> Ok, then I take it that this would be the preferred Python+FFI approach for
>> interfacing, right? ctypes is out of the loop?
>>
>> Stefan
>
> Ideally it would be a better FFI than ctypes in my opinion.
>
> Cheers,
> fijal
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev

The issue is not really to interface pypy with C, it obviously can.
The problem is really to do it the other way around. Cython is just
one example that wants to do it the other way around, but only because
it currently works that way.
It would be great if we would only ever go from Python into C
libraries and back again, but Python and C stacks can be interwoven
arbitrarily through callbacks (or directly by the library itself),
which are not uncommon at all in Cython. I think if RPython were
targeted (which sounds like a good idea), then there would still need
to be some mechanisms to go back from those C libraries into PyPy
land. It wouldn't need a large C API, but some minimalistic
functionality would need to be there, which I'm sure could be
supported by various different backends (think of things like
PyGILState_Ensure() and PyObject_Call()).

I think the FFI itself is a mere convenience.