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!
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)."
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?
Django does a bunch of magic which is challenging for the type checkers to handle well.
Also, it's also too bad we have three competing fast LSP/typechecker projects now We had zero 1 year ago.
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.
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?
(I was on the Python Typing Council and helped put together the spec, the conformance test suite, etc)
That said I'm very happy user of uv, so once Ty becomes ready enough will be happy to migrate.
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.
Mypy is trash. Nice to have a table to point to to prove it.
> At time of writing, many of the remaining rules require type inference and/or multi-file analysis, and aren't ready to be implemented in Ruff.
ty is actually a big step in this direction as it provides multi-file analysis and type inference.
(I work at Astral)
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)
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.
In fact as Jetbrains has been spending years chasing various rabbits including AI, instead of substantially improving or fixing PyCharm, without you steadily replacing/repairing big chunks of Pycharms functionality I would be miserable. If it came down to it, we would happily pay a reasonable license fee to use your tools as long as they stayed free for non-commercial usage.
I recently viewed tutorials on uv and ruff from Corey Schafer on youtube which were excellent
Hope to make these tools part of my defaults
Look forward a similar overview by Corey on ty :)
Curious ..is there any backstory to these library names?
It's fast too as promised.
However, it doesn't work well with TypedDicts and that's a show-stopper for us. Hoping to see that support soon.
> RUFF 0.14.9
> UV 0.9.18
> TY 0.0.2
> PYX Beta
> GITHUB
``` It's recommended to disable the language server from the Python extension to avoid running two Python language servers by adding the following setting to your settings.json:
{ "python.languageServer": "None" } ```
[1] https://github.com/astral-sh/ruff/blob/0bd7a94c2732c232cc142...
[2] https://github.com/astral-sh/ruff/blob/0bd7a94c2732c232cc142...
The point is you drop things such as types to enable rapid iteration which enables you to converge to the unknownable business requirements faster.
If you want slow development with types, why not Java?
> Akshually, are there any studies showing that cars riding 30 km/h kill less people than cars that ride 80 km/h?
[0] https://talkpython.fm/episodes/download/520/pyx-the-other-si...
It's not a prototyping language or a scripting language or whatever. It's just a language. And types are useful, especially when you can opt out of type checking when you need to. Most of the time you don't want to be reassigning variables to be different types anyway, even though occasionally an escape hatch is nice.
In my case they just add noise when reading code and make it more difficult to review
from anthropic.types import MessageParam
data: list[MessageParam] = [{"role": "user", "content": [{"type": "text", "text": ""}]}]
```
This for example works both in mypy and pyright. (Also autocompletion of typedict keys / literals from pylance is missing)
No, static typing is usually used AOT (most frequently at compile time), not usually at runtime (types may or may not exist at runtime; they don't in Haskell, for instance.)
Python type checking is also AOT, but (unlike where it is inextricably tied to compilation because types are not only checked but used for code generation) it is optional to actually do that step.
Python type annotations exist and are sometimes used at runtime, but not usually at that point for type checking in the usual sense.
I reported this as https://github.com/astral-sh/ty/issues/1994
Support for auto-completing TypedDict keys is tracked here: https://github.com/astral-sh/ty/issues/86
Educate yourself before making such claims.
ruff - "RUst Formatter".
ty - "TYpe checker"
uv - "Unified python packaging Versioner"? or "UniVersal python packaging"
> No, static typing is usually used AOT (most frequently at compile time), not usually at runtime (types may or may not exist at runtime; they don't in Haskell, for instance.)
In fact, Haskell then allows you to add back in runtime types using Typeable!
https://hackage.haskell.org/package/base-4.21.0.0/docs/Data-...
TL;DR: ty is an extremely fast Python type checker and language server, written in Rust, and designed as an alternative to tools like mypy, Pyright, and Pylance.
Today, we're announcing the Beta release of ty. We now use ty exclusively in our own projects and are ready to recommend it to motivated users for production use.
At Astral, we build high-performance developer tools for the Python ecosystem. We're best known for uv, our Python package manager, and Ruff, our linter and formatter.
Today, we're announcing the Beta release of the next tool in the Astral toolchain: ty, an extremely fast Python type checker and language server, written in Rust.
0s20s40styPyreflyPyrightmypy5.32s19.62s45.66s2.19s
Type checking the home-assistant project on the command-line, without caching (M4).
ty was designed from the ground up to power a language server. The entire ty architecture is built around "incrementality", enabling us to selectively re-run only the necessary computations when a user (e.g.) edits a file or modifies an individual function. This makes live updates extremely fast in the context of an editor or long-lived process.
0s1s2styPyrightPyrefly370.5ms2.60s4.5ms
Re-computing diagnostics in the language server after editing a file in the PyTorch project (M4).
You can install ty today with uv tool install ty@latest, or via our VS Code extension.
Like Ruff and uv, ty's implementation was grounded in some of our core product principles:
An obsessive focus on performance. Without caching, ty is consistently between 10x and 60x faster than mypy and Pyright. When run in an editor, the gap is even more dramatic. As an example, after editing a load-bearing file in the PyTorch repository, ty recomputes diagnostics in 4.7ms: 80x faster than Pyright (386ms) and 500x faster than Pyrefly (2.38 seconds). ty is very fast!
Correct, pragmatic, and ergonomic. With features like first-class intersection types, advanced type narrowing, and sophisticated reachability analysis, ty pushes forward the state of the art in Python type checking, providing more accurate feedback and avoiding assumptions about user intent that often lead to false positives. Our goal with ty is not only to build a faster type checker; we want to build a better type checker, and one that balances correctness with a deep focus on the end-user experience.
Built in the open. ty was built by our core team alongside dozens of active contributors under the MIT license, and the same goes for our editor extensions. You can run ty anywhere that you write Python (including in the browser).
Even compared to other Rust-based language servers like Pyrefly, ty can run orders of magnitude faster when performing incremental updates on large projects.
Your browser does not support the video tag.
Editing a central file in the PyTorch repository with ty (left) and Pyrefly (right). ty's incremental architecture is designed to make live updates extremely fast.
ty also includes a best-in-class diagnostic system, inspired by the Rust compiler's own world-class error messages. A single ty diagnostic can pull in context from multiple files at once to explain not only what's wrong, but why (and, often, how to fix it).


When assigning an invalid value to a dictionary key, ty surfaces both the type mismatch at the assignment site and the corresponding item declaration.
Diagnostic output is the primary user interface for a type checker; we prioritized our diagnostic system from the start (with both humans and agents in mind) and view it as a first-class feature in ty.


When importing an unresolved module, ty surfaces both the unresolved import at the import site and the corresponding Python version configuration.
If you use VS Code, Cursor, or a similar editor, we recommend installing the ty VS Code extension. The ty language server supports all the capabilities that you'd expect for a modern language server (Go to Definition, Symbol Rename, Auto-Complete, Auto-Import, Semantic Syntax Highlighting, Inlay Hints, etc.), and runs in any editor that implements the Language Server Protocol.
Following the Beta release, our immediate priority is supporting early adopters. From there, we're working towards a Stable release next year, with the gap between the Beta and Stable milestones largely focusing on: (1) stability and bug fixes, (2) completing the long tail of features in the Python typing specification, and (3) first-class support for popular third-party libraries like Pydantic and Django.
On a longer time horizon, though, ty will power semantic capabilities across the Astral toolchain: dead code elimination, unused dependency detection, SemVer-compatible upgrade enforcement, CVE reachability analysis, type-aware linting, and more (including some that are too ambitious to say out loud just yet).
We want to make Python the most productive programming ecosystem on Earth. Just as with Ruff and uv, our commitment from here is that ty will get significantly better every week by working closely with our users. Thank you for building with us.
ty is the most sophisticated product we've built, and its design and implementation have surfaced some of the hardest technical problems we've seen at Astral. Working on ty requires a deep understanding of type theory, Python runtime semantics, and how the Python ecosystem actually uses Python.
I'd like to thank all those that contributed directly to the development of ty, including: Douglas Creager, Alex Waygood, David Peter, Micha Reiser, Andrew Gallant, Aria Desires, Carl Meyer, Zanie Blue, Ibraheem Ahmed, Dhruv Manilawala, Jack O'Connor, Zsolt Dollenstein, Shunsuke Shibayama, Matthew Mckee, Brent Westbrook, UnboundVariable, Shaygan Hooshyari, Justin Chapman, InSync, Bhuminjay Soni, Abhijeet Prasad Bodas, Rasmus Nygren, lipefree, Eric Mark Martin, Tomer Bin, Luca Chiodini, Brandt Bucher, Dylan Wilson, Eric Jolibois, Felix Scherz, Leandro Braga, Renkai Ge, Sumana Harihareswara, Takayuki Maeda, Max Mynter, med1844, William Woodruff, Chandra Kiran G, DetachHead, Emil Sadek, Jo, Joren Hammudoglu, Mahmoud Saada, Manuel Mendez, Mark Z. Ding, Simon Lamon, Suneet Tipirneni, Francesco Giacometti, Adam Aaronson, Alperen Keleş, charliecloudberry, Dan Parizher, Daniel Hollas, David Sherret, Dmitry, Eric Botti, Erudit Morina, François-Guillaume Fernandez, Fabrizio Damicelli, Guillaume-Fgt, Hugo van Kemenade, Josiah Kane, Loïc Riegel, Ramil Aleskerov, Samuel Rigaud, Soof Golan, Usul-Dev, decorator-factory, omahs, wangxiaolei, cake-monotone, slyces, Chris Krycho, Mike Perlov, Raphael Gaschignard, Connor Skees, Aditya Pillai, Lexxxzy, haarisr, Joey Bar, Andrii Turov, Kalmaegi, Trevor Manz, Teodoro Freund, Hugo Polloli, Nathaniel Roman, Victor Hugo Gomes, Nuri Jung, Ivan Yakushev, Hamir Mahal, Denys Zhak, Daniel Kongsgaard, Emily B. Zhang, Ben Bar-Or, Aleksei Latyshev, Aditya Pratap Singh, wooly18, Samodya Abeysiriwardane, and Pepe Navarro.
We'd also like to thank the Salsa team (especially Niko Matsakis, David Barsky, and Lukas Wirth) for their support and collaboration; the Elixir team (especially José Valim, Giuseppe Castagna, and Guillaume Duboc), whose work strongly influenced our approach to gradual types and intersections; and a few members of the broader Python typing community: Eric Traut, Jelle Zijlstra, Jia Chen, Sam Goldman, Shantanu Jain, and Steven Troxler.
Finally, on a personal level, I'd like to highlight the core team (Alex, Andrew, Aria, Carl, David, Dhruv, Doug, Ibraheem, Jack, and Micha), who created ty from nothing and pushed it to be great from Day 1.