I have been tinkering with pypy source tree for a week now and came up with a following question - is there any way to build a rpython program as a shared object which exposes some of its functionality (say a list of functions) for standard cpython vm, in other words I want this functions to be invokable from python script via shared object import. When I try to build my program like so:
python rpython --shared -O2 some_program.py
libmyprogram-c.so actually gets generated, unimportable from cpython though. Should I use CFFI for cpython next or there is some sort of facility (decorator or something) in rpython framework that should cut it nicely?
There is no really convenient way to do that. As you're describing: write an RPython program, turn in into libmyprogram-c.so, and then access that C library from CPython e.g. with cffi.
In more details, you'd write the RPython source code such that the .so exports the C API of your choice, by using the decorator rpython.rlib.entrypoint.entrypoint_highlevel(). But then you get a C library that works at the level of C. There is nothing at all that helps you pass around a Python object---you only have C types. There is no notion of data structures like "list" or "dict" and no automatic lifetime management across the boundary, for example.
Moreover, debugging the RPython source code that makes libmyprogram-c.so is harder than debugging a regular C library. The usual recommendation is for an RPython program or library to be thoroughly tested before you even attempt to translate it to C, because at least you can debug when testing it on top of Python.
RPython only shines when you have a use for its garbage collector, tweaked towards high allocation rate, and---most importantly---its just-in-time compiler generator, producing a JIT compiler from the RPython program if the latter is some kind of dynamic interpreter. If you have no use for this, then RPython is a bad fit. If you do, however, it's a different story :-)