"We're building a new static type checker for Python"

[theLiminator]

Very excited for this, looks like it's built on top of pretty solid technical foundations (iirc, it uses salsa from rust for incremental type checking). I've found mypy pretty terrible. Pyright is okay (but requires node).

Ruff truly can become one tool to rule them all.

[IshKebab]

I agree, Mypy is awful. Pyright is very good but also quite slow, and its Node requirement is awkward in some cases (e.g. pre-commit).

A fast Rust based type checker would be amazing!

[dcreager]

> it uses salsa from rust for incremental type checking

This is true! We're also contributing salsa features upstream where we can, e.g. https://github.com/salsa-rs/salsa/pull/603

[sgarland]

I've avoided Pyright explicitly for that reason. I have a severe dislike of Node, and don't want it installed on my computer for any reason. I'm aware that this is a self-limiting position.

Anyway, agreed that this is very exciting news. Poetry was great, and then I found uv. It's... wow. It's really good.

[craigds]

Mypy is currently the only one that can handle Django projects (because it has a plugin system and there's a plugin that can import your django code to infer types)

Unfortunately that massively limits its performance too since loading a large django codebase is pretty slow.

[insane_dreamer]

I've found pyright to be limited in its ability to infer types, especially compared to Pycharm, which can resolve class inherence across multiple modules quite well. I noticed this when trying to use Zed instead of Pycharm.

[jasonpeacock]

It's hard to find details...apparently it's code named "red knot" (or "red_knot").

Here's the github issues filter linked in the screenshot:

https://github.com/astral-sh/ruff/labels/red-knot

And the best answer/description of what the type checker will be:

https://github.com/astral-sh/ruff/discussions/15149

[kittikitti]

I started learning Python when it was barely at version 1 precisely because there was no real static type checking. If I wanted that, I would just write the program in C or its variants. I wasn't excited about type hints because developers became super judgy if there weren't any. I just want to know why you're using Python if you want stronger typing and feel the need to change the entire language instead of using another one yourself.

[cobertos]

Progressive typing gives you the option to type check when and if you want or need it. You don't _have_ to type. If things get really hairy but you know it's right, you can focus on the code instead of the typing and efficiently complete your task.

There's also something fundamental about taking a dynamic language like Python or JavaScript and adding typing versus taking a static language and adding dynamic typing (e.g.`auto` in C#). The dynamic language allows modifications that are _really_ convenient if not a little hacky that you just can't easily express without big refactors in static codebases. Things like tagging objects with properties, making quick anonymous structs (before that became a thing in modern languages) so you can return tuples of values, other constructs like dynamic functions or whatever. Progressive typing is just so much more expressive

[jaredklewis]

Probably because a lot of programmers don't get to choose the language they are using. They have a job developing some existing app that is already written in Python, but they wish it wasn't Python. They don't have an option to rewrite the whole codebase in Rust or whatever, so the best they can do is advocate for Python to evolve to be more like languages they do like.

[rewgs]

Man, I feel the exact opposite. Working without types, even if it's just type hints, feels like I'm stumbling around in the dark. I want to know what stuff is, not just YOLO my way through everything.

Looking at my Python before I began using type hints and data structures such as dataclasses, typevars, etc I was still type-checking a function's argument, but it was very manual and messy. Nowadays, my code is so much cleaner, concise, less error-prone, and much easier to revisit after a long period away. IMO there isn't a single downside to leaning heavily into types, even if they're sorta "fake" like they are in Python.

[falcor84]

I personally just love Python type hinting for testing purposes. So I can avoid types while prototyping or playing with architecture, but once I have something I'm happy with, I find that adding types allows me to gain confidence in the program while having fewer tests, and generally making it easier to refactor further.

And full typing is also a great first step for rewriting in another language.

[taco_emoji]

I feel like if you think about it for 20 seconds you can come up with a lot of good reasons, so I question your motivation in posting this.

[ijustlovemath]

Python's got a pretty incredible library ecosystem, and it's easy to get a project up and running quickly. The big problems with it start to appear as you cross the 10k+ sloc / 3+ dev thresholds; if things are changing quickly, the iteration velocity the duck typing provides can quickly become a big problem.

Type hints fix this by allowing you to ensure your contracts are upheld while your team continues to move. If you don't find yourself needing them, you probably don't have a team that's trying to ship and iterate super quickly, or your project is still at the one-off script scale.

[baq]

C is basically untyped but makes you type out the types. This is not what modern type checking is; it’s usually the other way around - you specify types where you want them checked because it gives you confidence that the program is correct.

[mtalantikite]

The entire ML/AI ecosystem is in Python for the most part these days, so if anyone wants to get involved it means needing to touch Python to some degree. So, many developers might get handed projects that require working in Python, but would really prefer not to give up all the nice things that come from a modern statically typed language.

Personally, I'm one of those people that got converted over to statically typed languages, as I spent a large part of my early career in startups using Ruby. I don't think I could ever go back after using Go, TypeScript, and Rust over the past decade or so.

[tcdent]

typed python is amazing for building understandable applications. I will never go back.

you can obviously still use it untyped to hack together scripts, but I still find myself leaving annotations for clarity.

I've been using it since the mid 2.x days and find the style we were writing back then to be incredibly dated.

[RohMin]

I guess there's something about Python that just makes it really easy to read and write for me. I haven't found another language that fits the vibe. From my experience, the resentment towards stronger typing comes from developers misusing it.

[shlomo_z]

I am really excited.

Ruff is amazing, uv literally fixed all the python packaging issues we have, and now a type checker!!

Can't wait to see it!

[dcreager]

Bluesky cross-post for those who don't want to read the thread on X: https://bsky.app/profile/crmarsh.com/post/3lgvhzdfrps26

[timeon]

As someone without X or Bluesky, this link shows whole thread while X does not.

[StackTopherFlow]

Doing the lord's work

[esafak]

This is all very well but how are going to make money? They have taken VC investments.

[ehutch79]

My big question is django support.

Django has a lot of magic that makes type checking more difficult than it should be.

I'm not really expecting anything, even just the speed bump will be nice.

[aleksanb]

Agree with this.

All type checkers other than mypy (e.g. pyright, intellij) have ignored the level of plugin support necessary to make django work well, and so they are DOA for any large existing django codebase. Unless ruff decides to support such a dynamic interface as mypy's, it'll fare no better.

We use mypy with [django-stubs](https://github.com/typeddjango/django-stubs) which works ok nowadays.

There was an effort to create a typechecking plugin interface for dataclass-style transforms for python type checkers, but what was merged was so lacking that one couldn't even make something close to django-stubs with it.

[claytonjy]

is Django working towards using native types instead of all they stuff they invented before type hints existed?

[aitchnyu]

Will django-stubs work with other typecheckers?

Tangential, I'm waiting for Edgedb to become next SQL so all ORM moats like Django's are drained.

https://github.com/typeddjango/django-stubs

[adsharma]

It should be much easier to type check this:

https://adsharma.github.io/fquery-meets-sqlmodel/

https://github.com/adsharma/fastapi-shopping/blob/main/model...

[agumonkey]

Applaud the effort, but it's weird seeing python (and es6) living more and more on top of native static analyzers/transpilers .. at which point will they become a frontend syntax for ocaml or julia ? :p

[zem]

as someone working in this space, the idea is that most python code is implicitly statically typed anyway, in that your functions are only ever meant to be called with specific types for their arguments, and only return objects of a specific type. all that static type analysis does is to make that explicit via type annotations, and then verify that you have indeed used types correctly in your code. static compilers then say "well, if we know the static types of everything in this function, we can compile it to more efficient code, skipping all the dynamic lookups and runtime type checks and dispatching". typically there is an escape hatch that will fall back to regular python behaviour if your code is indeed dynamic (e.g. reflecting on a database schema to generate models at runtime), but losing the benefits of static analysis and optimisation.

if you would like to read more on the topic the keyword is "gradual typing"; in particular you might be interested in looking up stanza, a language designed around gradual types from the outset rather than retrofitting them on top of a dynamically typed language.

[snovymgodym]

> at which point will they become a frontend syntax for ocaml or julia ?

At no point.

What probably will happen is that both the JS and the Python reference implementations will have first class support for type systems which will allow them to generate optimized native code for the typed sections of your code while keeping the untyped sections as bytecode or as higher level compiled code (i.e. a bunch of runtime function calls dealing with tagged union objects).

[pjc50]

People aren't going to learn ocaml nor julia, nor can you easily call a python package from them nor run them in the browser against the DOM.

Javascript has a uniquely privileged position as the native browser language, and a couple of decades of effort has been expended on making it usable.

[monlockandkey]

They just need to add a task runner feature (already being worked on) and the one tool to rule them all would be complete. Package manager, linter, formatter, type checker, task runner. Am I missing something? Maybe a build tool?

https://github.com/astral-sh/uv/issues/5903

[roywashere]

I still hope they build a Heroku alternative. I think their work on uv might be some of the building blocks they would need?

[screye]

At the risk of sounding like a fanatic, I bet it will be great.

Everything Astral have put out has been a step improvement to my python dev flow. Until they disappoint me, I'm staying on this hype train.

[CapeTheory]

When it comes time to write Python 4, please just let these guys handle it.

[g_delgado14]

let him coooook

[nimish]

astral doing what the endless layers of admin/people in the PSF can't: solve actual problems python devs face

[egeres]

Astral has consistently surprised the python community with amazing tooling. It was a matter of time before they jumped into type checking. I think ruff and uv were good first MVPs for a small company with a highly talented team. I can't help but wonder if someday they'll attempt to build their own Python interpreter in Rust, or if that's overkill.

[intalentive]

I would use a statically-typed Python that you can compile into a binary for better performance. Step 1: Develop fast in regular Python. Step 2: Add type annotations and build.

[alias301]

You're in luck!

https://github.com/mypyc/mypyc

[pjc50]

Never mind performance, a python application that you can actually ship as a self-contained unit would be a major step forwards.

[fuzztester]

Mojo from Modular?

I've not checked it out enough yet, and it's early days for it anyway.

Just saying it may be worth keeping an eye on.

I've seen some videos of Chris Lattner talking about it.

https://www.modular.com/mojo

https://hn.algolia.com/?q=mojo

[aldanor]

Final piece of the puzzle will be one LSP to rule them all, unifying all previous work - aka python-analyzer.

[bmitc]

It's interesting to me that one of the most popular, if not the most popular, language in the world and one that is decades old has tooling that is constantly evolving and being reinvented and now in another language than itself. Contrast this with Rust and Elixir which have developed superior tooling in just a decade or so. I just started with real Python development in the past year and have already switched basic tooling!

[westurner]

Could it please also do runtime type checking?

(PyContracts and iContract do runtime type checking, but it's not very performant.)

That MyPy isn't usable at runtime causes lots of re-work.

[exabrial]

Wouldn't it make more sense to make a statically typed language? Like Crystal is to Ruby?

[sureglymop]

https://nitter.poast.org/charliermarsh/status/18846514820094...

[joshdavham]

This is exciting! I'd love to be able to use something other than mypy, especially if it's way faster!

[IshKebab]

Pyright is already 100x better than Mypy. Honestly there's no good reason to use Mypy.

It isn't much faster though so hopefully this will fix that.