[pypy-dev] Question on the future of RPython
sarvi at yahoo.com
Thu Sep 2 09:57:33 CEST 2010
I afraid people are missing the point here.
For an average engineer its better to be an expert of 1 language than be an
average at 4.
Thats my take on things.
Take Merurial(an SCM) 95% python 5%C and gives GIT a run for its money
This could be 95%Python and 5%RPython.
>From what I can tell writing RPython is still simpler than writing C/C++.
Garbage collection alone justifies its use in my opinion.
The option of the Interpreter during development is just huge amounts of icing
on the cake.
>From my reading on PyPy, thats why yall chose to write the PyPy in RPython.
Yall could have done in this C/C++ right?
So far as I can tell RPython is a strict subset of Python. I don't see why it
shouldn't continue to be.
And even if yall needed to make a very small set of static extension to RPython,
you wouldn't any worse that Cython and Shedskin.
I would still rather work with just one interpreter/compiler, say PyPy. Better
than PyPy/CPython for interpreter and Cython/Shedkin for compiling, with
interpreter support during development.
I am just seeing Cython/Shedskin as fragmentation of resources.
A lot more could accomplished if these projects came together.
----- Original Message ----
From: William Leslie <william.leslie.ttg at gmail.com>
To: Saravanan Shanmugham <sarvi at yahoo.com>
Cc: pypy-dev at codespeak.net
Sent: Thu, September 2, 2010 12:09:03 AM
Subject: Re: [pypy-dev] Question on the future of RPython
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
> 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
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.
More information about the Pypy-dev