Python Developer Tooling Handbook – Ty

ty and pyrefly find different bugs

Tim Hopper — Mon, 27 Apr 2026 00:00:00 +0000

Note

Update 2026-04-29: An earlier version of this post used a multi-line Liskov-violation panel from rich/_null_file.py as an example of ty catching a real protocol bug. That diagnostic turned out to be a ty false positive: ty reports the base parameter type as Buffer when checking overrides on subclasses of IO[str], even though the parameterization should resolve AnyStr to str. mypy and pyright are both silent on the same code. The “Where ty pulls ahead” section has been rewritten with a tuple-arity finding instead, and the conclusion’s reference to “Liskov panels” has been dropped. Thanks to a reader for the catch.

How Astral Uses Its Own Tools

Tim Hopper — Thu, 23 Apr 2026 09:00:00 -0400

Astral runs ruff, uv, and ty inside the repos that build them. Their pyproject.toml, .pre-commit-config.yaml, and CI files are public, and a walk through the three shows how the people making ruff, ty, and uv wire their own toolchain into the projects that produce it.

Build ty from source and type-check Python with it

The ruff repository ships ty as part of its crate tree. Three CI steps build ty from source and run it against the repo’s own Python:

Migrating from mypy to ty: Lessons from FastAPI

Tim Hopper — Fri, 03 Apr 2026 00:00:00 +0000

Sebastián Ramírez, creator of FastAPI, recently announced that all his Python projects now use ty for type checking. That includes FastAPI, Typer, SQLModel, Asyncer, and FastAPI CLI.

Migrating the projects wasn’t a hard switch. It was incremental, messy in the middle, and completed at different speeds across different projects. That pattern offers a useful template for anyone considering the same move.

Ramírez didn’t rip out mypy and replace it with ty in a single PR. Instead, he added ty alongside mypy and ran both checkers in parallel. Four of his five major repos still operate this way. Only SQLModel has fully dropped mypy.

OpenAI to Acquire Astral

Tim Hopper — Thu, 19 Mar 2026 00:00:00 +0000

OpenAI announced today that it will acquire Astral, the company behind uv, Ruff, and ty. The Astral team will join OpenAI’s Codex group after the deal closes, subject to regulatory approval.

What this means for Codex

Codex, OpenAI’s coding agent, has grown to over 2 million weekly active users, with 3x user growth and 5x usage increase since the start of 2026. Acquiring Astral gives OpenAI direct ownership of tools that millions of Python developers already depend on. OpenAI plans to integrate Astral’s tools more deeply into Codex so the agent can interact with the toolchain developers already use.

Charlie Marsh on uv, Coding Agents, and the Changing Open Source Contract

Tim Hopper — Tue, 24 Feb 2026 12:00:00 -0500

Charlie Marsh (founder of Astral, creator of ruff, uv, and ty) joined Michael Chow and Wes McKinney on The Test Set. They covered uv’s adoption strategy, how coding agents are changing Astral’s development process, and what’s happening to open source when writing code becomes cheap.

uv’s compatibility layer was the point

When uv first shipped, it only had uv pip install and uv venv. Some people found this odd. Charlie says it was deliberate:

ty is Built with AI

Tim Hopper — Fri, 02 Jan 2026 08:00:00 -0500

Tool creators are building their tools with AI coding assistants.

Boris Cherny, creator of Claude Code, didn’t open an IDE in December but wrote 200 PRs with Claude Code. Charlie Marsh, creator of ruff, uv, and ty, noted that all his PRs to ty were created with Claude Code. The tools building themselves.

Integration with Python Tooling

The handbook’s Modern Python Project Setup Guide for AI Assistants provides structured guidance so AI tools default to uv and modern patterns rather than falling back to pip commands.

ty: Astral's New Python Type Checker Released

Tim Hopper — Tue, 16 Dec 2025 22:43:00 -0500

Astral released ty, a Python type checker written in Rust, today. The company behind uv and Ruff designed ty as an alternative to mypy and pyright, with performance as a primary focus.

Speed Benchmarks

According to Astral’s benchmarks:

ty checks the home-assistant project in 2.19 seconds (20x faster than mypy’s 45.66 seconds)
After editing a file in PyTorch, ty recomputes diagnostics in 4.7ms (80x faster than pyright’s 386ms)

Key Features

ty includes several design choices that distinguish it from existing type checkers:

Analysis of the New Wave of Python Type Checkers

Tim Hopper — Wed, 17 Sep 2025 20:31:00 -0400

Rob Hand’s comparison of emerging type checkers is the first comprehensive look at three new Rust-based tools: ty (Astral), pyrefly (Meta), and zuban (David Halter).

Key Findings

Performance drives the rewrite. All three abandon Python implementations for Rust, targeting the bottlenecks that slow existing checkers on large codebases.

Conformance scores don’t predict usefulness. ty passes only 15% of the typing conformance suite’s tests but works well for everyday Python. The suite apparently focuses on edge cases most developers never hit.

ty's Breakthrough: Why Incremental Analysis Matters for Python

Tim Hopper — Mon, 11 Aug 2025 09:22:00 -0400

In a recent PyBytes podcast interview, Astral’s Charlie Marsh shared insights into what makes their new type checker ty unique and how it aims to address longstanding challenges in Python type checking.

What is ty?

ty serves dual purposes: it functions as a standalone command-line type checker (similar to mypy) and as a language server that powers IDE features like go-to-definition, code completion, and real-time diagnostics.

“We wanted to build a great type checker and a great language server, and they have things that are in common but they also have very different requirements,” Marsh explained. “If you don’t think about both of those from the start, you end up in a little bit of trouble.”

How Python's RFC Process Paved the Way for uv, Ruff, and Ty

Tim Hopper — Fri, 01 Aug 2025 15:22:00 -0400

Astral, an independent startup, has taken the Python world by storm over the last few years with three fast, robust Python developer tools:

ruff (linter and formatter)
uv (packaging and project management)
ty (static type checker, still under development)

These tools came from the mind of Charlie Marsh, who is neither a Python core developer nor directed by the Python Steering Council. While being independently developed, these tools work seamlessly within the established Python ecosystem. This success stems partly from Astral’s attention to guidelines established by the Python Enhancement Proposal (PEP) process over the last twenty-five years.

Comparison of the Two New Typecheckers

Tim Hopper — Wed, 28 May 2025 07:29:00 +0000

At PyCon 2025’s Typing Summit, participants saw the first demonstrations of Meta’s Pyrefly and Astral’s ty, two new Python type checkers with significant speed and analysis improvements.

Edward Li helpfully took notes and provided a right-up.

Here are some takeaways:

Both tools show substantial speed gains
- Pyrefly claims up to 1.8 million lines/sec (35× faster than Pyre, 14× faster than MyPy/pyright), while ty benchmarks show it running 2–3× faster than Pyrefly on real-world codebases.
The tools differ in their approach to type inference

Early Explorations of Astral's Red Knot Type Checker

Tim Hopper — Thu, 03 Apr 2025 15:19:00 +0000

Update (May 5, 2025): Red Knot has been renamed ty.

A recent blog post by Michael Jurasovic explores Astral’s upcoming static type checker, Red Knot. The tool is under active development with an alpha release targeted for PyCon 2025.

It's happening! A Python Type Checker from Astral

Tim Hopper — Wed, 29 Jan 2025 15:39:00 +0000

After months of speculation, Astral (creators of Ruff and uv) has officially announced their work on a new static type checker for Python. Built from the ground up in Rust, this tool aims to bring Astral’s signature focus on performance to Python’s static typing ecosystem.

Charlie Marsh, Astral founder, says that beyond performance, the project seeks to minimize “false positives, especially on untyped code, to make it easier for projects to adopt a type checker and expand coverage gradually over time, without being swamped in bogus type errors from the start.”