On Mon, Aug 19, 2013 at 9:06 AM, Michal Vyskocil <mvyskocil@suse.cz> wrote:
be very interesting and valuable (because of the relatively high resources it requires to translate pypy itself), but perhaps pypy itself isn't up to that task yet (having tons of important extension modules that cannot be supported without jumping through big hoops).
If pypy was a reasonably compatible replacement, I'd reconsider moving towards u-a
I think pypy needs a way to provide the equivalent of python C extensions in a distribution-friendly way to get there. Currently, the only (good) way to provide them, is by including an R-Python implementation during interpreter translation. That's completely opposite to package management. cpyext can't be considered, it's not "native" to pypy and its performance will never compare to R-Python implementations.
I would not say rpython is usefull to anything that to write an interpreter/JIT for some language. However the Python C API compatibility is an issue for pypy (as well as for any other alternative implementation).
Actually there are two reasonable ways for native modules - ctypes or cffi. The first one is in standard library, the later one is supported and developed by pypy devs and should fill the gap between alternative Python implementations and native modules. And of course, cffi is much easier to use than all other alternatives including ctypes, cython or raw C API.
ctypes and cffi handle interphasing with native libraries, be what I'm talking about, are C extension modules. Python objects implemented at a lower, native level. Like CPython's cPickle, for instance, or, more relevantly, psycopg2, mysql-python, pyzmq, and others of a similar nature: library bindings that go beyond just providing the native API calls of their C counterparts. ctypes is inherently unsafe, for instance, where an ABI mismatch will result in strange runtime errors, including segfaults, and cffi might work, but I haven't seen widespread use as a porting tools for the kinds of packages I mention, and I wouldn't call it easier to use than cython, having used cython extensively myself. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org