Please enlighten me about PyPy

[Claudio Grondi]

Steve Holden wrote:
> Kevin Yuan wrote:
> 
>>
>>
>> 21 Dec 2005 19:33:20 -0800, Luis M. González <luismgz at gmail.com 
>> <mailto:luismgz at gmail.com>>:
>>
>>     ... ...
>>     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