Hello again and welcome to our third blog on RustPython! Today we’ll be discussing the quality of the RustPython system, and how to protect it as the code evolves. For RustPython this is especially important as it is still in an early stage of its development, making clarity and technical debt hard to ignore. We’ll start by considering what the essential software quality processes are for RustPython, describe how it ensures these (hint: Continuous Integration is involved), and then look at the current quality of the code and the culture behind it.

Brief introduction For our last essay, we decided to create an architecture.md file for the RustPython repository. Since the current documentation coverage of the RustPython project is less than 10%, we feel creating an architecture.md will provide the most benefit. It will serve as a good way to help new contributors understand the code architecture of RustPython. In addition to this, it also closes the gap between occasional and core contributors.

From Vision To Architecture In the previous blog, we gave you a first impression of what RustPython looks like and what it aims to achieve. This time, we’ll be taking a look under the hood to find out what the main architecture of the interpreter looks like and how the individual components interact with each other. 🧐 Main architecture Choosing the main architectural styles or patterns used in an application is an important decision.

Many programming enthusiasts are enthused by the fresh new movement of ‘Rust’, the most loved programming language for the past five years, and Python, the most popular language for the past couple of years. Both languages are suitable for quick scripting and larger projects. What happens when you combine both? RustPython 😉 The arrival of RustPython brings yet another competitor to the various Python interpreters that are already out there. With the potential to become the default Python interpreter, it is interesting to further explore this Rust implementation of Python.