We’re building a new static type checker for Python, from scratch, in Rust.
From a technical perspective, it’s probably our most ambitious project yet. We’re about 800 PRs deep!
Like Ruff and uv, there will be a significant focus on performance.
The entire system is designed to be highly incremental so that it can eventually power a language server (e.g., only re-analyze affected files on code change).
Performance is just one of many goals, though.
For example: we're investing heavily in strong theoretical foundations and a consistent model of Python's typing semantics.
(We're lucky to have @carljm and @AlexWaygood on the team for many reasons, this is one of them.)
python-build-standalone has exploded in popularity, with over 70M downloads all-time.
But what is a "standalone" Python build?
It wasn't obvious to me at first! Initially, I didn't understand what problem was being solved or why it mattered...
First, some context on the problem.
Normally, when you build CPython on Linux or macOS, several system paths are hardcoded into the binary.
This is fine if you're building and installing Python on a single machine... but it's a problem if you want to pre-build Python and then distribute it to other machines, since those paths might be wrong!
Today, we're shipping a series of features that move uv beyond a pip alternative, and into an end-to-end solution for managing Python projects, command-line tools, single-file scripts, and even Python itself.
A collection of (sometimes contradictory) beliefs I've developed on building fast software...
Sometimes, performance just doesn't matter. If I make some codepath in Ruff 10x faster, but no one ever hits it, I'm sure it could get some likes on Twitter, but the impact on users would be meaningless.
And yet, it's good to care about performance everywhere, even when it doesn't matter. Caring about performance is cultural and contagious. Small wins add up. Small losses add up even more.
There's an extremely interesting conversation going on in Python right now around the future of performance.
It's centered on @colesbury's PEP 703, which makes the GIL optional (to be removed entirely in the future), but comes at a cost.
Here's my summary...
For context: The CPython interpreter isn't thread-safe, so the global interpreter lock ("GIL") exists to ensure that only one thread is actually executing code at a time.
PEP 703 includes changes to (1) make the interpreter thread-safe and (2) make the GIL optional.
It's agreed that removing the GIL would have an enormous performance benefit on multithreaded code. It would change Python dramatically.
But there appear to be two main hesitations to the PEP.