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

[Stefan Behnel]

Armin Rigo, 14.02.2012 13:13:
> the main problem is that the RPython-to-C translation that we
> do is not just a one-format traduction.  We need to tweak the
> intermediate code in various ways depending on various settings.  The
> way it is tweaked really depends on these settings in a way that
> cannot be captured just by C macros.  (If it could, we might have
> written the whole project in C instead of RPython in the first place.)
>  You would end up with a version of the Cython C code that only works
> on *some* kind of PyPy, like using the minimark GC, without any JIT
> support, and without sandboxing support.  (Just to add an example, I
> could also say "and without stackless support", but this is no longer
> true nowadays because we no longer rely on a transformation for
> stackless.)

Hmm, if that is so, how would you ever want to make PyPy bidirectionally
interface with anything at all? How does ctypes even work in PyPy? Is it
just that you're lucky that ctypes can be controlled completely from within
PyPy and doesn't let any internals leak into the outside world? Then how is
rffi supposed to do it better? And how are you planning to export numpypy
buffers to non-PyPy code?

It's one thing to export low-level data and simple C functions etc. to
external code. However, the open C-API of CPython is a serious part of its
success story. It's not just legacy code that uses it, it continues to be
an important part of the platform. If PyPy can't have such an API, that's a
serious drawback of the architecture.

Stefan