On 2 September 2010 15:54, Saravanan Shanmugham <[email protected]> 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 _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
