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 :)

you are viewing a single comment's thread
view the rest of the comments

[–] alsimoneau@lemmy.ca -2 points 21 hours ago (1 children)

I never understood the need for a Python type checker. If I wanted static typing I would code in Fortran.

[–] FizzyOrange@programming.dev 1 points 10 hours ago (1 children)

Just in case that's a genuine question, the reasons people like static types are:

Catch more bugs.
Catches bugs earlier (while you are writing the code). This is sometimes called "shift left".
Fewer tests needed.
Code is easier to understand.
Code is easier to navigate.
Refactoring is much easier.
Development speed is faster (due to the above points).

Often people say it slows development down but it's actually the opposite. Especially for large projects or ones involving multiple people.

The only downside really is that sometimes the types can get more complicated than they're worth, but in that case you have an escape hatch via the Any type.

[–] alsimoneau@lemmy.ca 1 points 5 hours ago

Thanks for the answer. It is a genuine question.

But don't you loose polymorphism? It seems like a big trade-off. For context I'm a scientist doing data analysis and modeling, so my view point is potentially significantly different than most of "the industry".

Your points 1-3 are handled by running the code and reading the error messages, if any. For 4-5 "ugly" code will be unreadable wether it's typed of not. For 6 refactoring now necessitate to change the types everywhere, which I imagine could be error prone and increase code inertia. And for 7 it would definitely slow down developpement untill you get familiar with the libraries and have tooling to automate stuff.

I can understand the appeal for enterprise code but that kind of project seems doomed to go against the Zen of Python anyways, so it's probably not the best language for that.