ty: Type Checker Rápido para Python

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, tipagem estática com mypy e protocols e 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:

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:

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:

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:

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.

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:

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:

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, tratamento de erros em Python e 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, Ruff e boas práticas Python para 2026.