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 _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
