That's great news! TIL that ty is also a language server, which means it replaces not only mypy, but also Pyright in Neovim/VSCode.

The title of this story should be "Announcing the Beta release of ty". A lot of people have been waiting for the beta specifically.

I've been using Pyrefly and loving it compared to Pyright, but they recently shipped some updates with crash bugs that forced me to pin to a previous version, which is annoying. Unfortunately my first impression of ty isn't great either. Trying to install the ty extension on the current version of Cursor says "Can't install 'astral-sh.ty' extension because it is not compatible with the current version of Cursor (version 2.2.20, VSCode version 1.105.1)."

Hopefully it gets added to this comparison:

https://htmlpreview.github.io/?https://github.com/python/typ...

If that table is anything to go by, Pyright is not to be underestimated.

I have briefly tried ty (LSP) in Emacs and it seems to work well so far. The only questionable thing I've encountered is that when the signature of a method is shown, the type annotations of some parameters seem to be presented in a particularly verbose form compared to what I'm used to - maybe they're technically correct but it can be bit much to look at.

Anyway, odds are pretty good that ty is what I will end up using long-term, so thanks and congrats on releasing the first beta!

How conformant is this, compared to e.g. mypy?

Not impressed because when tried ruff, and discovered that it doesn't replace (basic) pylint check https://github.com/astral-sh/ruff/issues/970 so we have ruff then pylint (and looking at the number of awaiting PR of ruff feels bad)

Too bad they did not benchmark Zuban, which is also promising.

Also, it's also too bad we have three competing fast LSP/typechecker projects now We had zero 1 year ago.

Very excited to see this. I thought that speed does not matter much for python tooling, but then I tried uv, and realized that I was wrong. The experience is just better. Looking forward to see more high performance quality tooling for Python.

Very exciting! I guess I'll have to wait for Django and Pydantic support to migrate to it on Zulip, but type checking was the last major linter that's still slow in Python.

Beautiful acknowledgment list, and congratulations on the beta release!

I really hope astral can monetize without a highly destructive rugpull, because they are building great tools and solving real problems.

I still don’t understand how a single language can have multiple (what is it now, half a dozen?) different type checkers, all with different behaviour.

Do library authors have to test against every type checker to ensure maximum compatibility? Do application developers need to limit their use of libraries to ones that support their particular choice of type checker?