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

[Maciej Fijalkowski]

On Tue, Feb 14, 2012 at 3:12 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> 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

I think CPython C API is a serious part of it's success because it's
"good enough for a lot of cases" not because it's necessary for it's
success. In my opinion a decent FFI (not ctypes, I mean a decent one)
and better performance would eliminate this need completely. From our
perspective then, CPython C API is just legacy.