How to learn RPython as a general purpose language
I tried downloading the archives of this list and grepping, but couldn't find an answer to this question. If it's been discussed to death and I missed it I apologize. I realize that it is not recommended to use RPython as a general purpose language, a front end to C if you will. My question is how one might learn how to do so, regardless. I'm also interested in reasons why it shouldn't be done (preferably ones that can be resolved). ## References I've found a comment on LtU suggesting that it is extremely hard to learn, yet a valuable skill if you can cut it: http://lambda-the-ultimate.org/node/1260#comment-13972 I've also found a hello world example from 2006 (humorously labeled part 1): http://radix.twistedmatrix.com/2006/12/how-to-do-something-with-rpython-part... Josh Gilbert.
In RPython, you can't call into other libraries, be they C or Python. Also, calling RPython from Python is "pretty unofficial and unsupported." Given that much of modern programming centers around connecting various libraries together, this makes RPython a poor choice for most practical work. At the moment, the most straight forward way to learn RPython is to learn Python, then learn the restrictions of RPython, since RPython is a subset of Python. The easiest way to do this is, basically, keep writing Python and seeing what the translator will and won't accept. Please correct me if I'm wrong; I've only spent a few days looking at RPython. Best, Martin Josh Gilbert wrote:
Martin C. Martin wrote:
You can call C libraries from rpython. There is even a doc here http://codespeak.net/pypy/dist/pypy/doc/rffi.html. Calling from Python to RPython is indeed pretty troublesome.
I think this is bad decision. Especially that translator might accept something and start behaving differently. Some docs are here http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#rpython, but it's indeed hard to deal with. RPython is similiar to C++ in a sense that one can write books about tricks. The main strangeness is that RPython is constructed out of live objects, which means that during initialization all python dynamism is allowed, but not after. This is sometimes hard to follow and also it's evolving a bit in time. I would suggest looking at various smaller language implementations (lang/ subdirectory in svn) and come to #pypy on freenode and ask. But it would be better if you have good reason why exactly you want to use it. Cheers, fijal :.
Martin C. Martin wrote:
No, that's pretty much correct. Another way to describe RPython is this analogy: Syntax and semantics of Python, speed of C, restrictions of Java and compiler error messages as penetrable as MUMPS (*) Kind regards, Alexander (*) http://en.wikipedia.org/wiki/MUMPS#Sample_Programs
Hi Josh, Josh Gilbert wrote:
I'm not sure I said it is 'extremely hard' or it is a 'valuable skill' - but i definitely said: """ Python is a subset of Python. The rules as to what the subset is vague indeed, but in short writing code without using dynamic language features post import time (ie the static-ness is based on code objects not python code) should be enough. These rules are fairly well documented and unlikely to change significantly in the future. The problem (IMHO) of promoting it is a language is that the tool chain is extremely non-user friendly and it is necessary to have a good understanding of how the flow graphs are created and how the several annotation passes work. All you will get is a stack trace in some obscure area of the annotation code for a compile error. :-) If one takes the time to learn how the above works then you have pretty useful language at your disposal. """ Well I wrote that many moons ago. And is more or less still true - except I understood pypy's tool chain better than I do now. After spending about 4-5 months rewriting a quite large application from python to rpython - I can say this about having a 'pretty useful language at your disposal': (a) the translated rpython code was faster than python (b) some parts were pretty much a copy and paste of the original python code and just a few tweaks to make it compile (c) some parts were a complete rewrite (d) the time taken for (b) and (c) was no less than it would of taken to write the code in say java or c++. (e) the end result is still some nice python code that was still readable and easy to modify. (f) a lot of niceties of using python go out the window such as no long waits for compiles, nice stack traces, run time introspection, no segmentation faults, etc etc (a), (b) and (e) are advantages (c), (d) and (f) are disadvantages. Of course if your application is interpretative and can make use of say the jit (and similar arguments for other features like the stackless transformation), then (d) would be a massive (colossal) effort that you get for free via pypy. (f) does also have the advantage than rpython is python and during development one can run with some interpreter. YMMV Cheers - Richard
Hi Richard, On Fri, Jan 25, 2008 at 11:10:32PM +0000, Richard Emslie wrote:
Thanks for this great summary of RPython :-) In particular, it's all too easy to overlook (c) at a first glance. Let me paraphrase this again: <strong> it's very likely that some parts of a typical Python programs cannot be simply tweaked until they are RPython! </strong> RPython is indeed designed to be some kind of new language in which to write algorithmic'ish code from scratch. It was not designed as a way to incrementally speed up parts of an existing Python program. The Python <-> RPython interfaces are there mostly for historical reasons and being deprecated because they get in the way of other features that we need more right now. These interfaces could be cleanly re-developed if there are people interested in pushing RPython there, but given the priorities and interests of the small group of people currently working on it, it doesn't look like it is going to happen soon. A bientot, Armin
In RPython, you can't call into other libraries, be they C or Python. Also, calling RPython from Python is "pretty unofficial and unsupported." Given that much of modern programming centers around connecting various libraries together, this makes RPython a poor choice for most practical work. At the moment, the most straight forward way to learn RPython is to learn Python, then learn the restrictions of RPython, since RPython is a subset of Python. The easiest way to do this is, basically, keep writing Python and seeing what the translator will and won't accept. Please correct me if I'm wrong; I've only spent a few days looking at RPython. Best, Martin Josh Gilbert wrote:
Martin C. Martin wrote:
You can call C libraries from rpython. There is even a doc here http://codespeak.net/pypy/dist/pypy/doc/rffi.html. Calling from Python to RPython is indeed pretty troublesome.
I think this is bad decision. Especially that translator might accept something and start behaving differently. Some docs are here http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#rpython, but it's indeed hard to deal with. RPython is similiar to C++ in a sense that one can write books about tricks. The main strangeness is that RPython is constructed out of live objects, which means that during initialization all python dynamism is allowed, but not after. This is sometimes hard to follow and also it's evolving a bit in time. I would suggest looking at various smaller language implementations (lang/ subdirectory in svn) and come to #pypy on freenode and ask. But it would be better if you have good reason why exactly you want to use it. Cheers, fijal :.
Martin C. Martin wrote:
No, that's pretty much correct. Another way to describe RPython is this analogy: Syntax and semantics of Python, speed of C, restrictions of Java and compiler error messages as penetrable as MUMPS (*) Kind regards, Alexander (*) http://en.wikipedia.org/wiki/MUMPS#Sample_Programs
Hi Josh, Josh Gilbert wrote:
I'm not sure I said it is 'extremely hard' or it is a 'valuable skill' - but i definitely said: """ Python is a subset of Python. The rules as to what the subset is vague indeed, but in short writing code without using dynamic language features post import time (ie the static-ness is based on code objects not python code) should be enough. These rules are fairly well documented and unlikely to change significantly in the future. The problem (IMHO) of promoting it is a language is that the tool chain is extremely non-user friendly and it is necessary to have a good understanding of how the flow graphs are created and how the several annotation passes work. All you will get is a stack trace in some obscure area of the annotation code for a compile error. :-) If one takes the time to learn how the above works then you have pretty useful language at your disposal. """ Well I wrote that many moons ago. And is more or less still true - except I understood pypy's tool chain better than I do now. After spending about 4-5 months rewriting a quite large application from python to rpython - I can say this about having a 'pretty useful language at your disposal': (a) the translated rpython code was faster than python (b) some parts were pretty much a copy and paste of the original python code and just a few tweaks to make it compile (c) some parts were a complete rewrite (d) the time taken for (b) and (c) was no less than it would of taken to write the code in say java or c++. (e) the end result is still some nice python code that was still readable and easy to modify. (f) a lot of niceties of using python go out the window such as no long waits for compiles, nice stack traces, run time introspection, no segmentation faults, etc etc (a), (b) and (e) are advantages (c), (d) and (f) are disadvantages. Of course if your application is interpretative and can make use of say the jit (and similar arguments for other features like the stackless transformation), then (d) would be a massive (colossal) effort that you get for free via pypy. (f) does also have the advantage than rpython is python and during development one can run with some interpreter. YMMV Cheers - Richard
Hi Richard, On Fri, Jan 25, 2008 at 11:10:32PM +0000, Richard Emslie wrote:
Thanks for this great summary of RPython :-) In particular, it's all too easy to overlook (c) at a first glance. Let me paraphrase this again: <strong> it's very likely that some parts of a typical Python programs cannot be simply tweaked until they are RPython! </strong> RPython is indeed designed to be some kind of new language in which to write algorithmic'ish code from scratch. It was not designed as a way to incrementally speed up parts of an existing Python program. The Python <-> RPython interfaces are there mostly for historical reasons and being deprecated because they get in the way of other features that we need more right now. These interfaces could be cleanly re-developed if there are people interested in pushing RPython there, but given the priorities and interests of the small group of people currently working on it, it doesn't look like it is going to happen soon. A bientot, Armin
participants (6)
-
Alexander Schremmer -
Armin Rigo -
Josh Gilbert -
Maciek Fijalkowski -
Martin C. Martin -
Richard Emslie