--- title: "ty: Type Checker Rápido para Python" url: "https://python.dev.br/blog/ty-type-checker-python-rust/" markdown_url: "https://python.dev.br/blog/ty-type-checker-python-rust.MD" description: "Conheça o ty da Astral, veja como testar esse type checker para Python no terminal e entenda onde ele se destaca frente a mypy e Pyright." date: "2026-04-10" author: "Equipe python.dev.br" --- # ty: Type Checker Rápido para Python Conheça o ty da Astral, veja como testar esse type checker para Python no terminal e entenda onde ele se destaca frente a mypy e Pyright. O ecossistema Python ganhou mais uma ferramenta para acompanhar em 2026: o **`ty`**, um **type checker** e também **language server** implementado em Rust pela Astral, empresa já conhecida por projetos como o Ruff e o UV. A promessa é ambiciosa: trazer checagem de tipos com foco pesado em performance, boa experiência no editor e adoção gradual em bases de código reais. Para quem já usa **mypy** ou **Pyright**, a pergunta natural é: vale a pena olhar para isso agora? A resposta curta é sim, principalmente se você acompanha ferramentas modernas de produtividade em Python. Mas é importante entender o contexto: o projeto ainda está em fase de evolução rápida, então o melhor uso hoje é para experimentação, comparação e aprendizado. Neste artigo, vamos ver o que é o `ty`, por que ele está chamando atenção, como testar no terminal e em quais cenários ele pode fazer sentido. ## O que é o ty? O `ty` é uma ferramenta de análise estática voltada para **tipagem em Python**. Segundo a documentação pública do projeto, ele foi desenhado para ser extremamente rápido e também servir como base para recursos de editor, funcionando como language server. Em termos práticos, a proposta combina: - checagem de tipos no terminal; - análise incremental rápida; - integração com IDEs e editores; - diagnósticos ricos; - suporte a adoção gradual em projetos parcialmente tipados. Esse posicionamento é interessante porque ataca uma dor comum: times querem melhorar a tipagem, mas nem sempre conseguem aceitar ferramentas lentas ou uma curva de adoção muito rígida. Se você ainda está consolidando a base de tipos, pode ser útil rever também nossos conteúdos sobre [type hints em Python](/glossario/type-hints/), [tipagem estática com mypy](/blog/tipagem-estatica-python-mypy/) e [protocols e tipagem estrutural](/blog/python-protocols-tipagem-estrutural/). ## Por que o ty está chamando atenção? O principal motivo é o mesmo que impulsionou outras ferramentas da Astral: **velocidade**. A documentação do projeto destaca desempenho muito alto em comparação com checkers tradicionais, além de análise incremental pensada para o fluxo de desenvolvimento no editor. Isso importa bastante em projetos grandes, onde rodar verificação de tipos pode virar uma etapa lenta demais no feedback loop. Outro ponto importante é a experiência de uso. O `ty` não quer ser apenas um binário para CI; ele também mira: - autocomplete e navegação; - hover com contexto de tipos; - code actions; - auto-import; - inlay hints; - diagnósticos contextualizados. Ou seja, a proposta é competir não só em checagem pura, mas também em **DX**. ## Como começar rapidamente A forma mais simples de testar o `ty` hoje é via `uvx`, sem precisar instalar nada globalmente: ```bash uvx ty check ``` Esse comando executa a checagem no projeto atual. Em muitos casos, esse já é o jeito mais rápido de validar se a ferramenta faz sentido para seu repositório. Se quiser experimentar em um projeto mínimo, você pode criar um exemplo como este: ```python from dataclasses import dataclass @dataclass class Usuario: nome: str idade: int def saudacao(usuario: Usuario) -> str: return f"Olá, {usuario.nome}!" usuario = Usuario(nome="Diego", idade="31") print(saudacao(usuario)) ``` Salve como `app.py` e execute: ```bash uvx ty check app.py ``` O objetivo é justamente ver se a ferramenta detecta a inconsistência de tipo em `idade`, já que o campo foi anotado como `int`, mas recebeu uma string. ## Exemplo com função mal tipada Outro caso simples para testar é misturar tipos de retorno: ```python def calcular_total(precos: list[float]) -> float: if not precos: return "0.0" return sum(precos) ``` Aqui existe um erro óbvio: a função promete retornar `float`, mas em um ramo devolve `str`. Esse tipo de bug costuma passar despercebido sem type checking, principalmente em bases com muita lógica condicional. Ferramentas como `ty`, `mypy` e `Pyright` ajudam exatamente nesse tipo de prevenção. ## Comparando a proposta com mypy e Pyright Embora ainda seja cedo para decretar substituições, já dá para comparar o posicionamento de cada ferramenta. | Ferramenta | Foco principal | Linguagem | Perfil típico | |------------|----------------|-----------|---------------| | mypy | tipagem estática tradicional | Python | projetos maduros e ecossistema consolidado | | Pyright | tipagem + editor | TypeScript | uso forte em VS Code e feedback rápido | | ty | tipagem + language server + performance | Rust | experimentação moderna e DX com alta velocidade | O `mypy` segue muito relevante, especialmente pela maturidade e pelo histórico de adoção em projetos reais. O Pyright também é forte, principalmente pela experiência no editor. Já o `ty` entra como um candidato interessante para quem quer um fluxo muito rápido e está disposto a acompanhar uma ferramenta em evolução. ## Adoção gradual faz diferença Muitos times evitam tipagem porque acreditam que precisam tipar tudo de uma vez. Na prática, não funciona assim. Ferramentas modernas ganham espaço justamente quando permitem: - começar por arquivos críticos; - conviver com código legado; - ajustar severidade por pasta ou arquivo; - suprimir casos pontuais com clareza; - evoluir aos poucos sem travar o time. Esse ponto é importante porque a realidade da maioria das empresas brasileiras não é um projeto greenfield impecável. Normalmente existe uma mistura de código novo, legado, scripts internos e integrações antigas. Se o `ty` realmente entregar bem essa adoção gradual, ele pode se tornar uma peça forte do fluxo de engenharia moderno em Python. ## Exemplo de arquivo parcialmente tipado Veja um exemplo comum em projetos reais: ```python from typing import Any def normalizar_payload(payload: dict[str, Any]) -> dict[str, str]: resultado = {} for chave, valor in payload.items(): if valor is None: continue resultado[chave] = valor return resultado ``` Esse código parece inocente, mas há um detalhe: `resultado` promete valores `str`, enquanto `valor` vem como `Any`. Dependendo do dado recebido, você pode acabar retornando inteiros, booleanos ou objetos inesperados. Uma versão melhor seria: ```python from typing import Any def normalizar_payload(payload: dict[str, Any]) -> dict[str, str]: resultado: dict[str, str] = {} for chave, valor in payload.items(): if valor is None: continue resultado[chave] = str(valor) return resultado ``` Esse tipo de ajuste parece pequeno, mas reduz bugs em serialização, APIs e integrações. Para reforçar essa base, vale também revisar nossos artigos sobre [Pydantic e validação de dados](/blog/pydantic-validacao-dados-python/), [tratamento de erros em Python](/blog/tratamento-de-erros-python/) e [APIs REST com FastAPI](/blog/apis-rest-com-fastapi/). ## Vale usar em produção agora? A resposta mais honesta é: **depende do seu apetite para novidade**. Como o projeto ainda está amadurecendo, o melhor cenário hoje costuma ser: - testar localmente; - comparar resultados com mypy ou Pyright; - experimentar a integração no editor; - avaliar performance em projetos maiores; - acompanhar breaking changes antes de padronizar no time. Se sua empresa depende de máxima estabilidade e política conservadora de tooling, talvez o `ty` ainda entre primeiro como experimento. Já para times que gostam de adotar cedo ferramentas modernas, ele pode ser uma aposta muito interessante. ## Onde o ty pode se destacar mais? Os cenários mais promissores hoje parecem ser: - projetos grandes que sofrem com lentidão na análise; - times que valorizam integração forte com o editor; - codebases que querem subir o nível de tipagem gradualmente; - equipes que já usam Ruff e UV e gostam do ecossistema Astral. Existe também um fator cultural importante: ferramentas rápidas tendem a ser usadas com mais frequência. E, em engenharia, feedback curto quase sempre melhora a qualidade do código. ## Conclusão O **`ty`** ainda está em fase de amadurecimento, mas já merece radar de quem trabalha profissionalmente com Python. A combinação de **performance**, **type checking** e **language server** aponta para uma direção muito alinhada com o que o ecossistema moderno espera: ferramentas rápidas, integradas e pensadas para o fluxo real do desenvolvedor. Ele não apaga a relevância de `mypy` ou `Pyright`, mas mostra que a disputa por melhor experiência de tipagem em Python está longe de terminar — e isso é ótimo para a comunidade. Se você quer acompanhar outras ferramentas que estão modernizando o dia a dia em Python, leia tamb��m nossos artigos sobre [UV](/blog/uv-gerenciador-pacotes-python/), [Ruff](/blog/ruff-linter-formatador-python/) e [boas práticas Python para 2026](/blog/boas-praticas-python-2026/). O ty, assim como uv e Ruff, é escrito em Rust — a linguagem que está por trás da revolução de performance no tooling Python. Se você quer entender por que Rust é a escolha da Astral para essas ferramentas, vale explorar o ecossistema.