[pypy-dev] Question on the future of RPython

[William Leslie]

On 2 September 2010 15:54, Saravanan Shanmugham <sarvi at yahoo.com> wrote:
>
> I understand from various threads here,  that RPython is not for general purpose
> use.
> Why this lack of Focus on general use.

Because then we would have to support that general use.

Python benefits from being reasonably standardised, you can be sure
that most python you write will run on any implementation that
supports the version you are targetting. On the other hand, if you are
mangling cpython or pypy bytecode, you are asking for trouble. Rpython
is an example of such an implementation detail - we* might like to
change features of it here or there to better support some needed
pattern.

Introducing yet another incompatable and complicated language to the
python ecosystem is not a worthwhile goal in itself.

* Just my opinion. Others might feel like standardising some amount of
rpython is a worthwhile idea.

> They are so focused on this awesome final product vision that they fail to
> realize the awesome potential of some if its intermediate side deliverables.
>
> PyPy is definitely gaining momentum.
> But as a strategy to build that momentum, and gain new converts it should put
> some focus on some of its niche strengths.
> Things other python implementions cannot do.
>
> One such niche is its RPython and RPython Compiler.
> No other python implementation can convert python programs to executables.

I can't see why you would ever want to do this - if you use py2exe or
the like instead, you get a large standard library and a great
language to work in, neither of which you get if you use rpython.

> I am seeing growing interest in writing Rpython code for performance critical
> code and even potentially compiling it to binaries.

The intention is to get almost the same performance out of the JIT.
For those that actually care about the last few percent, it would be
nicer to provide hints to generate specialised code at module compile
time, that way you can still work at python level.

> Is it possible the PyPy team may be understating the significance of RPython?
> Am I crazy to think this way? :-)

Supporting better integration between app-level python and other
languages that interact with interpreter level would be nice. CLI
integration is good, and JVM integration is lagging just a little. But
once you can interact with that level, there are much saner languages
that you could use for your low-level code than rpython - languages
/designed/ to be general purpose languages.

At the moment, the lack of separate compilation is a real issue
standing in the way of using rpython as a general purpose language, or
even as an extension language. Having to re-translate *everything*
every time you want to install an extension module is not on. Even C
doesn't require that.

The other is that type inference is global and changes you make to one
function can have far-reaching consequences. The error messages when
you do screw up aren't very friendly either.

If you want a low-level general purpose language with type inference
and garbage collection that has implementations for every platform
pypy targets, there are already plenty of options.

-- 
William Leslie