Tobias Wrigstad
I am a professor in computer science at Uppsala University where I do research on programming language design and implementation. In the last years, my main interests have been memory management and concurrency safety which I have explored through type systems and run-time systems. In the context of Python, I currently work on PEP795, and its intended continuation (see e.g. https://dl.acm.org/doi/10.1145/3729313), on garbage collection and data-race freedom in Java, secure compilation for Erlang, and more. Python user since 2000.
Session
Python is losing the GIL, and it is not handing you a concurrency model in return.
Free-threading gives you parallelism, but safety is left as an exercise for the reader. The standard answer -- threads, locks and queues -- is the toolkit Java and C++ have spent twenty years trying to escape, and Python is a worse place to use it. Classes, modules and globals are mutable objects reachable from almost anywhere, so sharing is the default rather than the exception. This is leaves the door open for data races.
One of Python's strengths has been kindness to its users: garbage collection, strong typing, powerful libraries. Concurrency deserves the same treatment: deadlock-free and with data races manifesting as debuggable exceptions instead of inexplicable values.
In this talk, I will start with some of the fundamental pitfalls concurrent programming, and then describe a vision for a concurrent Python that comes with batteries included. At its simplest, support for deep immutability, so that data which cannot change can be shared without locks or copies. Then add regions, groups of objects that can be accessed together or not at all -- like a lock that knows which objects it guards, and catch attempts to reach past it. And finally behaviours, where you declare the data a task needs and the scheduler runs it once that data is yours alone. This model is deadlock-free and data-race free.
None of this is speculative. You can pip install bocpy today^1, and we are bringing it to free-threaded Python. Immutability is working its way through the PEP process; regions run in a CPython branch you can build.
The question is not whether Python can run in parallel, but what
it hands you when it does.
^1 So far, only for multiple sub interpreters.