Se você trabalha com Python e usa mypy, já conhece a rotina: rodar o type checker num projeto grande e esperar. Esperar bastante. O mypy leva 45 segundos para checar o Home Assistant inteiro. O ty, da Astral, faz o mesmo em 2,19 segundos.

O ty é a terceira ferramenta que a Astral coloca no ecossistema Python, depois do ruff (linter) e do uv (gerenciador de pacotes). As três seguem a mesma fórmula: reescrever em Rust algo que desenvolvedores Python usam todo dia e que sempre foi lento demais. Até aqui, a fórmula funcionou. O ruff substituiu o Flake8 e o isort para milhares de projetos. O uv fez o pip parecer uma ferramenta de outra era. Agora a pergunta é se o ty consegue fazer o mesmo com o mypy.

A Astral e a aposta na toolchain Python

A Astral foi fundada em 2023 por Charlie Marsh, o criador do ruff. A empresa levantou 4 milhões de dólares em seed liderado pela Accel, com participação de Guillermo Rauch (fundador da Vercel), Solomon Hykes (fundador do Docker) e David Cramer (fundador do Sentry). O perfil dos investidores diz bastante sobre a tese: gente que construiu ferramentas de infraestrutura para desenvolvedores e entende que performance de tooling não é luxo.

A estratégia é ambiciosa. Em vez de criar ferramentas isoladas, a Astral está montando uma toolchain unificada para Python:

  • ruff para linting e formatação (substitui Flake8, isort, Black, pyflakes)
  • uv para gerenciamento de pacotes e ambientes virtuais (substitui pip, pip-tools, virtualenv, pipx)
  • ty para type checking e language server (quer substituir mypy, Pyright e Pylance)

Todas escritas em Rust. Todas com performance como prioridade número um. O ruff tem mais de 45 mil stars no GitHub. O uv já é o package manager padrão em projetos novos para muita gente. O ty acumulou 17,4 mil stars antes mesmo de sair do beta.

O que é o ty e por que existe

O ty (pronuncia-se "tee-why") é um type checker estático e language server para Python. O projeto nasceu dentro do repositório do ruff com o codinome Red-Knot e foi renomeado para ty por volta de maio de 2025, quando a Astral lançou a primeira versão pública experimental na PyCon 2025.

A motivação é direta: mypy e Pyright funcionam, mas têm problemas reais. O mypy é escrito em Python (com mypyc para compilação) e sofre com performance em projetos grandes. O Pyright é rápido o suficiente para uso em IDE, mas está atrelado ao ecossistema Microsoft/VS Code via Pylance e usa TypeScript internamente.

O ty tenta resolver os dois problemas ao mesmo tempo. Por ser escrito em Rust, ganha performance bruta. Por ter sido projetado desde o início como language server, oferece uma experiência de editor que não depende de um único vendor.

Algumas capacidades que o diferenciam:

  • Tipos interseção de primeira classe que outros type checkers não suportam nativamente
  • Type narrowing avançado com análise de alcançabilidade sofisticada
  • Análise incremental de granularidade fina projetada para atualizações rápidas durante edição
  • Language server integrado com code navigation, completions, code actions, auto-import e inlay hints

Performance: os números

Os benchmarks do ty são o argumento mais forte a seu favor. A Astral publicou comparativos detalhados no seu blog oficial — os números abaixo vêm dessa fonte.

Sem cache, o ty é consistentemente entre 10x e 60x mais rápido que mypy e Pyright. Os números variam por projeto:

  • Home Assistant (projeto Python de grande porte): ty checa em 2,19 segundos. O mypy leva 45,66 segundos. Isso é 20x mais rápido.
  • PyTorch (codebase massiva): após editar um arquivo central, o ty recalcula diagnósticos em 4,7 milissegundos. O Pyright leva 386ms (80x mais lento). O Pyrefly da Meta leva 2,38 segundos (500x mais lento).

Esses números de recálculo incremental importam mais do que os de cold start para o uso diário. Quando você salva um arquivo no editor e precisa ver os erros de tipo atualizados, a diferença entre 4,7ms e 386ms é a diferença entre feedback instantâneo e uma pausa perceptível.

A arquitetura que permite isso é construída sobre o Salsa, um framework de computação incremental em Rust. O ty rastreia dependências entre funções e módulos de forma granular. Quando você muda uma função, ele recalcula apenas o que depende daquela função, sem recontar o resto do projeto.

ty vs mypy vs Pyright vs Pyrefly

O ecossistema de type checking para Python nunca teve tanta competição. Além do ty, a Meta lançou o Pyrefly (também escrito em Rust) como substituto do seu Pyre interno. Junto com mypy e Pyright, são quatro opções ativas.

mypy

O type checker original e mais adotado. Escrito em Python. Definiu muitas convenções que as ferramentas mais novas tentam manter compatibilidade. O problema é performance: em projetos grandes, rodar mypy no CI pode levar minutos. Suporta plugins (como mypy-django e mypy-sqlalchemy) que nenhum outro type checker replica ainda.

Pyright

Escrito em TypeScript, alimenta o Pylance no VS Code. Rápido o suficiente para uso em IDE e com boa cobertura de features do sistema de tipos do Python. A limitação é o acoplamento ao ecossistema Microsoft: o Pylance (versão IDE do Pyright) é closed-source e exclusivo do VS Code.

Pyrefly

O type checker da Meta, lançado em maio de 2025. Escrito em Rust, promete 1,8 milhão de linhas por segundo. Na prática, o ty é 2-3x mais rápido que o Pyrefly em cold start de codebases reais como PyTorch. O Pyrefly segue uma filosofia de inferência mais agressiva, inferindo união de tipos concretos mesmo sem anotações. Já tem extensão para VS Code e sandbox online.

ty

O mais rápido nos benchmarks, com a melhor performance incremental. Segue a "garantia gradual": type checking nunca adiciona erros a código que funciona. A desvantagem atual é maturidade: o ty passa cerca de 15% dos testes de conformidade do ecossistema Python, contra 58% do Pyrefly e 69% do zuban (outro projeto menor). Isso significa que o ty ainda emite falsos positivos em situações que outras ferramentas já resolveram.

Instalação e uso na prática

A forma mais rápida de experimentar o ty é via uvx (o runner de ferramentas do uv):

uvx ty check

Isso baixa o ty, cria um ambiente temporário e roda o type checker no diretório atual. Para instalar globalmente:

uv tool install ty@latest

Ou pelo instalador standalone:

curl -LsSf https://astral.sh/ty/install.sh | sh

Depois de instalado, o uso básico é direto:

ty check

O comando analisa todos os arquivos Python no diretório e subdiretórios. Para checar um arquivo específico:

ty check src/main.py

O ty também funciona como language server. Se você usa o VS Code, a extensão oficial ty-vscode conecta o language server ao editor. Ao abrir um projeto Python, o ty fornece diagnósticos em tempo real, auto-complete com tipos inferidos, code navigation e sugestões de import.

Um pyproject.toml com configuração mínima:

[tool.ty.rules]
unresolved-import = "error"
possibly-unbound = "warn"

Limitações e o que falta

O ty está em beta e a Astral é transparente sobre isso. Algumas limitações concretas para quem está avaliando a adoção:

Conformidade de tipos ainda baixa. Os 15% nos testes de conformidade significam que o ty vai emitir diagnósticos incorretos em código válido. Em um teste prático, um usuário reportou 1.599 diagnósticos do ty em uma codebase onde o Pyright encontrou apenas 10 (todos corretos). O ty precisa melhorar a inferência antes de ser confiável como gate de CI.

Sem suporte a plugins. Quem usa mypy-django, mypy-sqlalchemy ou plugins similares não tem equivalente no ty. Projetos Django e SQLAlchemy dependem pesadamente de plugins para type checking correto de querysets e models.

Framework support limitado. Pydantic e Django ainda não têm suporte direto. O roadmap da Astral lista ambos como prioridade para o 1.0, mas não há data definida.

Ecossistema de editores em construção. A extensão oficial existe para VS Code. Outros editores precisam configurar o language server manualmente via LSP.

O roadmap para o 1.0 estável em 2026 inclui: conformidade acima de 60%, suporte direto a Pydantic e Django, modo strict (que force anotações de tipo), sistema de plugins e mais otimizações de performance.

Conclusão

O ty está na mesma fase em que o uv estava quando lançou o primeiro beta: rápido o suficiente para impressionar, incompleto o suficiente para não substituir o incumbente no dia a dia de todo mundo. O uv levou cerca de um ano para chegar ao ponto em que projetos grandes começaram a adotá-lo como padrão. Se o ty seguir o mesmo ritmo, o segundo semestre de 2026 pode ser o ponto de inflexão.

Para quem quer experimentar agora, o melhor cenário é um projeto pessoal ou uma codebase sem dependência pesada de plugins de mypy. Rode uvx ty check no seu projeto, compare os diagnósticos com o que o mypy ou Pyright retornam, e avalie se os falsos positivos são toleráveis. Se forem, o ganho de velocidade compensa. Se não, espere o 1.0.

O que já está claro é que a Astral está construindo algo que o ecossistema Python precisava há tempo: uma toolchain coesa, rápida e com uma empresa por trás que tem incentivo econômico para mantê-la. Ruff, uv e ty juntos cobrem linting, formatação, gerenciamento de pacotes e type checking. Se os três atingirem maturidade, a experiência de desenvolver em Python vai ser outra.

Referências pesquisadas nesta publicação