Ty: A fast Python type checker and LSP
42 comments
·December 16, 2025frou_dh
hauntsaninja
Note: while spec conformance is important, I don't recommend using it as the basis for choosing a type checker. It is not representative of the things that most users actually care about (and is not meant to be).
(I was on the Python Typing Council and helped put together the spec, the conformance test suite, etc)
_carljm
We'll be adding ourselves to that table soon. We'll have some work to catch up with pyright on conformance, but that's what the time between now and stable release is for.
progbits
pyright is very good, but there is also https://docs.basedpyright.com/latest/ which improves on it further.
That said I'm very happy user of uv, so once Ty becomes ready enough will be happy to migrate.
WD-42
Pyright has been great. But it’s slow. Speed of a LSP does matter for UX. Excited to see how much ty improves on this.
IshKebab
Pyright is really really good. Anyone that doubts that 10x engineers exist, just go and look at Eric Traut. He's pretty much written it single handedly. Absolute machine.
Mypy is trash. Nice to have a table to point to to prove it.
buibuibui
Oh my, I just looked him up. He is the developer of Virtual Game Station - a PS1 emulator that I used in the past to play PS Isos on my Windows ME PC! What a legend.
shrumm
Thanks Astral team! We use Pydantic heavily, and it looks like first class support from Ty is slated for the stable release, we'd love to try it.
While we wait... what's everyone's type checking setup? We run both Pyright and Mypy... they catch different errors so we've kept both, but it feels redundant.
https://htmlpreview.github.io/?https://github.com/python/typ... suggests that Pyright is a superset, which hasn't matched our experience.
Though our analysis was ~2 years ago. Anyone with a large Python codebase successfully consolidated to just Pyright?
hauntsaninja
Mentioned this in another comment, but the spec conformance suite is not representative of the things users care about (nor is it meant to be).
The spec mostly concerns itself with the semantics of annotations, not diagnostics or inference. I don't really recommend using it as the basis for choosing a type checker.
(I was on the Python Typing Council and helped put together the spec, the conformance test suite, etc)
klysm
I really hope astral can monetize without a highly destructive rugpull, because they are building great tools and solving real problems.
tabbott
Yeah their work thus far has been an incredible public service to the Python community.
collinmcnulty
I am so pleased by ty’s stance that I should not have to add annotations to satisfy the type checker. I ripped out last type checker out because it was constantly nagging us about technicalities, but ty immediately found issues where we annotated that a duct was an acceptable input, but actually doing so would break things.
modeless
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)."
ocamoss
(pyrefly maintainer here) If you haven't already, please file an issue for that crash on the [Pyrefly repo](https://github.com/facebook/pyrefly) as well :)
charliermarsh
If there's anything else accompanying the error, do you mind filing an issue? I've been using the ty extension with Cursor for weeks and am having trouble reproducing right now.
modeless
That's the full error. It shows up in a dialog box when I press the install button. I'm on macOS, connected with the Anysphere Remote SSH extension to a Linux machine.
If I choose "install previous version" I am able to install the pre-release version from 12 hours ago without issue. Then on the extension page I get a button labeled "Switch to Release Version" and when I press it I get an error that says "Can't install release version of 'ty' extension because it has no release version." Filed a GitHub issue with these details.
In the meantime, the previous version appears to be working well! I like that it worked without any configuration. The Pyrefly extension needed a config tweak to work.
_carljm
https://forum.cursor.com/t/newly-published-extensions-appear... suggests that there's some kind of delayed daily update for new VSCode extension versions to become available to Cursor? It seems likely that's what is happening here, since ty-vscode 0.0.2 was only published an hour or two ago.
_carljm
I can reproduce this; we're looking into it.
pansa2
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?
WD-42
You’re talking about a duck typed language with optional type annotations. I love python but that’s a combination that should explain a bit why there are so many different implementations.
mirashii
> Do library authors have to test against every type checker to ensure maximum compatibility?
Yes, but in practice, the ecosystem mostly tests against mypy. pyright has been making some inroads, mostly because it backs the diagnostics of the default VS Code Python extension.
> Do application developers need to limit their use of libraries to ones that support their particular choice of type checker?
You can provide your own type stubs instead of using the library's built-in types or existing stubs.
akdor1154
Wow, even if it wasn't so fast, I'd be tempted to use this solely due to their support of intersection (A & B) types! This is a sore omission from the standard python typing system.
Ch00k
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.
f311a
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.
iamdanieljohns
The guy behind Zuban should've put his project out the in open way earlier. I'd love to see both projects succeed, but in reality it should become one.
0cf8612b2e1e
Without digging too deep- what is the Django story?
Django does a bunch of magic which is challenging for the type checkers to handle well.
selcuka
Ty doesn't support Django yet, and it doesn't have a plugin system, so third party developers can't improve it. If you need Django support, it is better to stick to mypy or pyright for the time being.
syiblet
The codebase has none of the rust code. In fact even the python code in the code base is mostly just scripts for updating version tags and etc...
Seems like the code isn't actually open source which to me is a bit concerning. At the very least, if ya'll want to release it like this please be clear that you're not open source. The MIT license in the repo gives the wrong impression.
woodruffw
The ty repo contains the ruff repo[1] as a submodule, where the remainder of the code is. It is indeed open source, the layout is just indirect at the moment because of code-sharing between the tools.
simonw
I think that's because most of the code for `ty` is tucked away in the `ruff` codebase: https://github.com/astral-sh/ruff/tree/main/crates/ty - it's all MIT licensed.
bobthecowboy
At least as of a couple months ago, `ty` was actually being developed in the `ruff` repo (per an pdocast interview the devs did on Talk Python), so that might be why the `ty` repo looks empty (and pulls in ruff as a git submodule).
tabbott
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.
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!