q1. pypy is the interpreter, a RPython program which can interpret Python code, there is no output language, so we can't consider it as a compiler, right?
PyPy is similar to CPython, both has a compiler+interpreter. CPython has a compiler written in C that compiles Python to Python VM bytecode then executes the bytecode in an interpreter written in C. PyPy has a compiler written in RPython that compiles Python to Python VM bytecode, then executes it in PyPy Interpreter written in RPython.
q2. Can compiler py2rpy exist, transforming all Python programs to RPython? In which language it's written is irrelevant. If yes, we get another compiler py2c. What's the difference between pypy and py2rpy in nature? Is py2rpy much harder to write than pypy?
Can a compiler py2rpy exists? Theoretically yes. Turing completeness guarantees so.
One method to construct py2rpy is to simply include the source code of a Python interpreter written in RPython in the generated source code. An example of py2rpy compiler, written in Bash:
// suppose that /pypy/source/ contains the source code for pypy (i.e. Python -> Nothing RPython)
cp /pypy/source/ /tmp/py2rpy/pypy/
// suppose $inputfile contains an arbitrary Python source code
cp $inputfile /tmp/py2rpy/prog.py
// generate the main.rpy
echo "import pypy; pypy.execfile('prog.py')" > /tmp/py2rpy/main.rpy
cp /tmp/py2rpy/ $outputdir
now whenever you need to translate a Python code to RPython code, you call this script, which produces -- in the $outputdir -- an RPython main.rpy, the RPython's Python Interpreter source code, and a binary blob prog.py. And then you can execute the generated RPython script by calling rpython main.rpy.
(note: since I'm not familiar with rpython project, the syntax for calling the rpython interpreter, the ability to import pypy and do pypy.execfile, and the .rpy extension is purely made up, but I think you get the point)
q3. Is there some general rules or theory available about this?
Yes, any Turing Complete language can theoretically be translated to any Turing Complete language. Some languages may be much more difficult to translate than other languages, but if the question is "is it possible?", the answer is "yes"
q4. ...
There is no question here.
Your exact technical solution and implementation seem somewhat niche. I did however work for a company where putting something live in a turned off state was common. In our case it was a winforms application with a flag in the database or config file that could turn the feature off and on, but I'm hoping some of my experiences can assist with the problems you're seeing here.
THE GAIN
Once the code is put live, even if it isn't used, it is a tick in a box and the deployment has at least been proven. This however, is the only upside.
THE PAIN
Minor revisions break the new functionality
Once the big change goes in, sometimes even the simplest subsequent change can cause this to unravel. Because the big change isn't actually live, it often gets missed in the testing or isn't considered in later designs.
YAGNI
You shouldn't be writing code unless you need it. If you need it, you should deploy it. If you've delayed turning the new code on, new requirements may have come to light meaning that the code could and should have been written better.
Technical debt
This in some ways is the worst outcome. The new code is never turned on. Bigger priorities come in and the new code is parked. It is too much of a risk to back it out and so it remains in the deployment, clogging up the code base and hogging resource.
Performance
Even though the new feature isn't visible. Sometimes related processing still takes place behind the scenes meaning the application degrades. As far as the user goes this is lose-lose. There is no new functionality and yet the system is performing slower.
The switchover fails
Due to minor subsequent changes or unforeseen circumstances on the live system, sometimes the switchover simply fails. The best scenario here is that you can simply turn it off again but if data is affected you could have a major issue on your hands.
SUMMARY
As with all things of this ilk, if it comes off - it looks like sheer brilliance. The release has gone in ahead of time and a magic switch makes the new functionality just work. But it rarely happens like this. Even if it does, the rare failures should immediately set alarm bells ringing that this is poor deployment practice.
Best Answer
No.
In general, the performance of a language implementation is primarily dependent on the amount of money, resources, manpower, research, engineering, and development spent on it.
And specifically, the performance of a particular program is primarily dependent on the amount of thought put into its algorithms.
There are some very fast interpreters out there, and some compilers that generate very slow code.
For example, one of the reasons Forth is still popular, is because in a lot of cases, an interpreted Forth program is faster than the equivalent compiled C program, while at the same time, the user program written in Forth plus the Forth interpreter written in C is smaller than the user program written in C.