Steve Holden wrote: > Kevin Yuan wrote: > >> >> >> 21 Dec 2005 19:33:20 -0800, Luis M. González <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>>: >> >> ... ... >> This implementation requires a minimal core, writen in a restricted >> subset of python called "rpython". This subset avoids many of the >> most >> dynamic aspects of python, making it easier to authomatically >> translate >> it to C through a tool that uses top-notch type inference techniques. >> >> >> Why not directly write the minimal core in C? >> >> > Because then you'd have to maintain it in C. This way, once you have the > first working translator you can translate it into C to improve its > performance, and use it to translate the *next* working translator, and > so on. Consequently your maintenance work is done on the Python code > rather than hand-translated C. > > Fairly standard bootstrapping technique, though it's sometimes difficult > to appreciate the problems involved in writing a compiler for language X > in X itself. Typical is the fact that the compiler for version m has to > be written in version (m-1), for example :-) > > used-to-do-that-stuff-for-a-living-ly y'rs - steve
I am glad someone asked the question about PyPy, because I need same enlightenment. Reading what has been written up to now I would like to present here my current understanding to get eventually corrected when got something the wrong way. Do I understand it right, that : Translating Python code to C for compilation is the way to avoid the necessity to write a Python compiler as a hand-coded Assembler code for each platform (i.e. Operating System / Processor combination)? This hand-coding is already done by the people providing a C-compiler for a platform and it can be assumed, that a C-compiler is always available, so why dig that deep, when in practice it could be sufficient to begin at the abstraction level of a C-compiler and not hand-coded Assembler? Sticking to ANSI C/C++ will make it possible to become multi platform without the necessity of writing own pieces of hand-coded Assembler for each platform what is usually already done by others providing that platform and the C compiler for it. So to use PyPy for creating a Python based Operating System where e.g. IDLE replaces the usual command line interface and Tkinter becomes the core of the GUI, it will be sufficient to replace the step of translation to C code and compilation using a C compiler by an in Assembler hand-coded Python compiler for each specific platform? The expectation to become faster than CPython with the PyPy approach I understand as a hope, that creating another Python engine architecture (i.e. hierarchy of software pieces/modules the entire Python scripting engine consist of) can lead to improvements not possible when sticking to the given architecture in the current CPython implementation. After it has been demonstrated the PyPy can be faster than the current CPython implementation it will be sure possible to totally rewrite the CPython implementation to achieve same speed by changing the architecture of the elementary modules. Is this maybe what causes confusion in understanding the expectation that PyPy can come along with a speed improvement over CPython? The fact, that another architecture of elementary modules can lead to speed improvement and the fact, that it can sure be also then implemented in the CPython approach to achieve the same speed, but would need a total rewrite of CPython i.e. duplication of the PyPy effort? Claudio -- http://mail.python.org/mailman/listinfo/python-list
