Any future "super speed" Python efforts would probably do well to build on the amazing work that PyPy has done in teasing apart an optimization-friendly subset of the language in the form of RPython, and building the rest of it in that language.
Like, focus on further optimizing the RPython runtime rather than starting from scratch.
That doesn't really make sense -- there is no "RPython runtime". There is a PyPy runtime written in RPython.
RPython isn't something that's exposed to PyPy users. It's
meant for writing interpreters that are then "meta-traced". It's not for writing applications.
It's also not a very well-defined language AFAIK. It used to change a lot and only existed within PyPy.
I'm pretty sure the PyPy developers said that RPython is a fairly unpleasant language to write programs in. It's meant to be meta-traceable and fast, not convenient. It's verbose, like writing C with Python syntax.
The PyPy interpreter is written in RPython, but is a full Python interpreter with a JIT. When you compile PyPy, it generates C files from RPython sources, which are then compiled with a normal C compiler into a standalone binary.
RPython is both a language (a very ill-defined subset of Python... pretty much defined as "the subset of Python accepted by the RPython compiler"), and a tool chain for building interpreters. One benefit of writing an interpreter in RPython is that, with a few hints about the interpreter loop, it can automatically generate a JIT.
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.)
Like, focus on further optimizing the RPython runtime rather than starting from scratch.