https://xcancel.com/charliermarsh/status/1884651482009477368
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.)
Another goal: minimizing false positives, especially on untyped code, to make it easier for projects to adopt a type checker and expand coverage gradually over time, without being swamped in bogus type errors from the start.
We haven't publicized it to-date, but all of this work has been happening in the open, in the Ruff repository.
All driven by a uniquely great team: @carljm, @AlexWaygood, @sharkdp86, @MichaReiser, @DhruvManilawala, @ibraheemdev, @dcreager.
I'm learning so much from them.
Warning: this project is not ready for real-world user testing, and certainly not for production use (yet). The core architecture is there, but we're still lacking support for some critical features.
Right now, I'd only recommend trying it out if you're looking to contribute.
For now, we're working towards an initial alpha release. When it's ready, I'll make sure you know :)
I don't think a powerful type system can be added to python effectively. Even more convinced of this after reading "minimize false positives".
Otoh, how strong of a type system is required for effective development? Probably what can be shoehorned into python tbh.
I think your last sentence hits the nail on the head. It's not perfect but it's good enough. There are some pains and edge cases but it still makes a night and day difference. This is my experience after introducing typing to the entire codebase in my work project over the course of last year.
In my experience, it’s a manageable trade off.
You allow for Python “magic” at the cost of type safety. Or you forgo magic for types, and the resiliency that comes with it.
Day to day, you don’t need magic. With good application of hinting you can stop many bugs before they appear.
When you do need magic, you can usually construct it to work within the type system, or at the very least easily ringfence the tainted typeless code the magic introduced.
The sync/async contradiction is much worse to wrangle.
How powerful do you want it? Python's type system is actually pretty good already and relatively sound when checked with Pyright (not Mypy though).
It's not Typescript-level, but it's better than e.g. Java or C++.
The main problem is Python developers writing code that can't be statically type checked. E.g. using magically generate method names via
__dict__or whatever (I think lxml does that).I'm on the more powerful the better side. So for me, Scala is the weakest type system I like working with.
Practically tho: aside from the issues you mention, the type checker for python would be a great aid for a broader range of developers than myself!
i don't believe it's possible either. For example the tree walker of the ast module takes the node passed to it, checks its type, gets its name, then looks for the method with that dynamically looked up name in your implementation of the tree walker and if it does (the user might not have implemented a visit method for that type of node), calls it and passes the node to it. All of this at runtime.