Hacker News Reader

Comment by mikepurvis | Hacker News Reader

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.

View on HN

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.

Why does RPython exist? It seems to be a subset of Python that can be optimized.

Why not use a faster language to write the interpreter, like C?

This is not meant to be a hostile question, I am just confused as to why PyPy exists

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

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.)

> optimization-friendly subset of the language in the form of RPython, and building the rest of it in that language.

I'm assuming 99% of normal python users are not using anything outside of the RPython subset, correct?

RPython's restrictions [1] are quite strict - I'd say its more likely that 99% of normal Python does use features that aren't supported by RPython.

[1] https://rpython.readthedocs.io/en/latest/rpython.html

The libraries they depend on probably are, though.

Reply on news.ycombinator.com