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

Armin Rigo arigo at tunes.org
Tue Feb 14 13:13:24 CET 2012


Hi Fijal,

On Tue, Feb 14, 2012 at 10:50, Maciej Fijalkowski <fijall at gmail.com> wrote:
> The thing is noone seriously works on the cython's pypy backend, so
> the dirty hacks seem like a very good solution short-to-mid term.

Someone feel free to try them out.  However I'm generally negative
about the outcome and its portability.

Please do keep in mind however that generating C code and having
custom macros to compile it either for CPython or for PyPy is *not*
going to work --- unless someone very carefully designs some very
clever missing piece and we place a number of restrictions about the
cases where it works.

Stefan: 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.)

For this reason, I remain convinced that the best approach for Cython
on PyPy is instead to have Cython generate pure Python code that would
use some API in the form of a built-in Python module.  ctypes may
work, but custom alternatives may be better.  The built-in module can
be implemented just once on PyPy (and optionally on CPython too,
mostly for testing).


A bientôt,

Armin.


More information about the pypy-dev mailing list