Python was designed in an era of mostly single-core machines, where concurrency was typically not parallel, and Dennard scaling made us rely on ever-faster single core CPUs coming onto the market every year. In this context, Python’s Global Interpreter Lock (GIL)-based design is easily motivated: only one thread may interpret bytecodes at a time in a Python program. This buys a lot of simplicity for your runtime, but it also means that throwing more cores at a Python program does not make it go faster.

Python 3.12 introduced the ability to run multiple Python interpreters in a single OS process, each with its own GIL. Each sub-interpreter runs in isolation from the other sub-interpreters and isolation is enforced by using a serialisation protocol to transfer data from one sub-interpreter to another. Every sub-interpreter has its own private heap, managed by a combination of reference counting and tracing GC dealing with cyclic data. This setup should feel familar to Erlang developers.

Cheeseman et al’s Behaviour-oriented Concurrency (BoC) is a promising technique for expressing concurrency in imperative programming, and delivers guarantees of data-race freedom and dead-lock freedom. As part of a multi-year project for adding BoC to Python, we have recently arrived at an intermediate step that we lovingly refer to as PyErlang. PyErlang enhances the sub-interpreters model with an ability to share immutable data by reference across interpreters, without making one process dependent on GC in another.

This talk is about the core of PyErlang: how to retro-fit immutability onto a mature language around a culture that embraces reflection and monkey-patching. I will discuss challenges at both the language-level and the implementation-level, and how we handle cyclic immutable garbage without tracing GC.