Ty:一个快速的 Python 类型检查器和 LSP
Announcing the Beta release of ty

原始链接: https://astral.sh/blog/ty

## ty:一种新型快速 Python 类型检查器 Astral 团队,Ruff 和 uv 的开发者,宣布 **ty** 进入 Beta 阶段。ty 是一种用 Rust 构建的、新型且极快的 Python 类型检查器和语言服务器。作为 mypy、Pyright 和 Pylance 的替代方案,ty 旨在更快*且*更好。 性能是关键重点:ty 的速度始终比现有工具快 10-60 倍,甚至在没有缓存的情况下。增量更新——例如在编辑期间——非常迅速(例如,PyTorch 中为 4.7 毫秒,而 Pyright 中为 386 毫秒)。 除了速度,ty 还优先考虑正确性和可用性,具有诸如交集类型、高级类型缩小以及受 Rust 编译器启发的清晰、上下文诊断等功能。它支持标准的语言服务器协议功能,以便与 VS Code 等编辑器集成。 该团队计划明年发布稳定版本,重点是稳定性、功能完善以及对 Pydantic 和 Django 等库的支持。最终,ty 将集成到 Astral 工具链中,以启用高级功能,例如死代码消除和依赖分析。 ty 现在可以通过 `uv tool install ty@latest` 和 VS Code 扩展获得。

## ty Beta 版本总结 Astral 发布了 **ty** 的 beta 版本,这是一款新的快速 Python 类型检查器和语言服务器,旨在改进现有的工具,如 mypy 和 pyright。一个关键的设计目标是最大限度地减少对显式类型注释的需求,同时仍然提供强大的检查。 讨论强调了在选择类型检查器时,除了规范一致性之外的其他重要因素——包括类型推断、诊断、配置、速度和编辑器集成。虽然 pyright 因速度而受到赞扬,但用户对 ty 的潜在改进感到兴奋,特别是它对交集类型的支持。 一些用户表达了对与现有工具(如 Django)的兼容性以及项目开源性质的担忧(ty 的代码主要在 ruff 仓库中)。Astral 团队强调他们致力于解决这些问题并欢迎反馈。此次发布引发了关于 Python 中静态类型检查的价值以及类型检查器激增的争论,一些人提倡整合。
相关文章

原文

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:

  1. 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!

  2. 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.

  3. 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.

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, 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, and wangxiaolei.

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.

联系我们 contact @ memedata.com