On Jan 17, 10:37 am, "Brendan Miller" <catph...@catphive.net> wrote: > What's the point of RPython? By this, I don't mean "What is RPython"? > I get that. I mean, why?
This is more or less covered in the FAQ: "The restrictions are to ensure that type inference (and so, ultimately, translation to other languages) of RPython programs is possible. These restrictions only apply after the full import happens, so at import time arbitrary Python code can be executed." http://codespeak.net/pypy/dist/pypy/doc/faq.html#id25 > The goals of the pypy project seems to be to create a fast python > implementation. I may be wrong about this, as the goals seem a little > amorphous if you look at their home page. The home page itself is ambiguous, and does oversell the performance aspect. The *actual* goal as outlined by their official docs is to implement Python in Python, at every level. If this means utilising a less-dynamic subset of Python for the lower levels, its -still- at least more-Python-than-C. "PyPy is both: * a reimplementation of Python in Python, and * a framework for implementing interpreters and virtual machines for programming languages, especially dynamic languages." http://codespeak.net/pypy/dist/pypy/doc/faq.html#id11 The PyPy devs feel that this will allow them to more easily experiment with optimising the interpreter for greater speeds, but that isn't one of the stated goals (just, apparently, their 'secret' one). > This RPython thing seems like a totally unnecessary intermediate step. > Instead of writing an implementation of one language, there's an > implementation of two languages. My understanding is that the 'higher' level Python language features are implemented on top of the restricted RPython features, so it's more of an organic growth of one language than two separate implementations. > A lot of the performance boost you > get from a static language is that knowing the types at compile time > lets you inline code like crazy, unroll loops, and even execute code > at compile time. > > RPython is a statically typed language because I guess the developers > associate static languages with speed? Doesn't the first paragraph above state the same thing that you question in the next? > Except that they use it to > generate C code, which throws away the type information they need to > get the speed increase. Huh? I thought the goal was to write a fast > dynamic language, not a slow static one? They're not just generating C code, they currently also target LLVM, JVM and CLI. > Is this going anywhere or is this just architecture astronautics? Well, they actually seem to have achieved some substantial gains, so I think it's unfair to imply that the project isn't based on pragmatic objectives. Their initial JIT prototype failed to work as well as expected, and they've spent some time re-thinking the approach; I'm happier to wait for a stably performing JIT that can be improved over time than a short term gain. > The RPython project seems kind of interseting to me and I'd like to > see more python implementations, but looking at the project I can't > help but think that they haven't really explained *why* they are doing > the things they are doing. A lot of this is covered in the FAQ. Whether you agree with their approach or not, they're the ones actively pushing this effort forward. It's been a few months since the last update, but the PyPy status blog may have more information for you. At the very least, it's a venue to discuss your concerns directly with the PyPy devs. http://morepypy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
