Basically because it can be "meta-traced", and C can't (at least not easily).
The whole point of the PyPy project is to write a more "abstract" Python interpreter in Python.
VMs written in C force you to commit to a lot of implementation details, while PyPy is more abstract and flexible. There's another layer of indirection between the interpreter source and the actual interpreter/JIT compiler you run.
See PyPy's approach to virtual machine construction
Building implementations of general programming languages, in
particular highly dynamic ones, using a classic direct coding approach, is typically a long-winded effort and produces a result that
is tailored to a specific platform and where architectural decisions
(e.g. about GC) are spread across the code in a pervasive and invasive way.
Normal Python and PyPy users should probably pretend that RPython doesn't exist. It's an implementation detail of PyPy. (It has been used by other experimental VMs,
but it's not super popular.)
The whole point of the PyPy project is to write a more "abstract" Python interpreter in Python.
VMs written in C force you to commit to a lot of implementation details, while PyPy is more abstract and flexible. There's another layer of indirection between the interpreter source and the actual interpreter/JIT compiler you run.
See PyPy's approach to virtual machine construction
https://scholar.google.com/scholar?cluster=36453268015981472...
This sentence explains it best:
Building implementations of general programming languages, in particular highly dynamic ones, using a classic direct coding approach, is typically a long-winded effort and produces a result that is tailored to a specific platform and where architectural decisions (e.g. about GC) are spread across the code in a pervasive and invasive way.
Normal Python and PyPy users should probably pretend that RPython doesn't exist. It's an implementation detail of PyPy. (It has been used by other experimental VMs, but it's not super popular.)