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. Sarvi ----- Original Message ---- From: William Leslie <[email protected]> To: Saravanan Shanmugham <[email protected]> Cc: [email protected] 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 <[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
