Anúncio do lançamento da beta do ty

• ty, um verificador de tipos e servidor de linguagem Python ultrarrápido escrito em Rust, foi lançado em versão beta
• Foi projetado como alternativa ao mypy, Pyright e Pylance, oferecendo desempenho 10 a 60 vezes mais rápido
• Com uma arquitetura incremental, recalcula apenas as partes necessárias quando o código é alterado, maximizando a velocidade de resposta em tempo real
• Com foco em precisão e usabilidade, oferece suporte a recursos modernos do sistema de tipos, como tipos de interseção, estreitamento avançado de tipos e análise de alcançabilidade
• A Astral planeja desenvolver o ty, junto com o Ruff e o uv, como ferramenta central do ecossistema Python

---

Visão geral do ty

• ty é um verificador de tipos e servidor de linguagem para Python desenvolvido pela Astral e implementado em Rust
  • Foi projetado como uma alternativa muito mais rápida ao mypy, Pyright e Pylance
  • Já é usado em vários projetos internos da Astral e, nesta fase beta, também é recomendado para usuários externos
• A Astral é a equipe que cria ferramentas de desenvolvimento de alto desempenho para o ecossistema Python e é conhecida pelo uv (gerenciador de pacotes) e pelo Ruff (linter e formatador)

Desempenho e arquitetura

• O ty foi projetado com uma estrutura centrada em servidor de linguagem e adota um processamento incremental que reexecuta apenas as operações necessárias quando um arquivo é modificado
  • Como resultado, a velocidade de atualização em tempo real no editor é extremamente rápida
• Mesmo ao executar sem cache, é 10 a 60 vezes mais rápido que mypy e Pyright
  • Exemplo: ao modificar arquivos principais do repositório do PyTorch, a velocidade de recálculo dos diagnósticos foi de 4,7 ms, 80 vezes mais rápida que o Pyright (386 ms) e 500 vezes mais rápida que o Pyrefly (2,38 segundos)
• Mesmo em projetos de grande porte, a diferença de desempenho em atualizações incrementais chega a várias dezenas de vezes

Sistema de tipos e precisão

• O ty oferece suporte a tipos de interseção (intersection types), estreitamento avançado de tipos (advanced type narrowing) e análise de alcançabilidade baseada em tipos (reachability analysis)
  • Esses recursos permitem fornecer feedback de tipos mais preciso e reduzir falsos positivos desnecessários
• O objetivo não é apenas aumentar a velocidade, mas construir um verificador de tipos que melhore tanto a precisão quanto a experiência do usuário

Sistema de diagnósticos

• O ty inclui um sistema avançado de diagnósticos inspirado no sistema de mensagens de erro do compilador Rust
  • Em uma única mensagem de diagnóstico, ele apresenta o contexto de vários arquivos ao mesmo tempo, mostrando com clareza a causa do problema e o caminho para a solução
  • Exemplo: ao atribuir uma chave inválida a um dicionário, exibe junto o local da incompatibilidade de tipo e o local da declaração
• A saída de diagnósticos é a interface central do ty e foi projetada com uma estrutura fácil de entender tanto para pessoas quanto para IA

Recursos do servidor de linguagem

• O ty pode ser usado em qualquer editor com suporte a LSP (Language Server Protocol), como VS Code e Cursor
  • Oferece todos os recursos modernos de servidor de linguagem, como ir para definição, renomear símbolo, autocompletar, importação automática, realce semântico de sintaxe e inlay hints
• Pode ser instalado por meio da extensão do VS Code e também via CLI com o comando uv tool install ty@latest

Planos futuros

• Após a beta, os objetivos de curto prazo são reforçar a estabilidade e corrigir bugs, completar a especificação de tipos do Python e dar suporte a Pydantic e Django
• No longo prazo, a ideia é expandir o ty como motor de recursos semânticos da cadeia de ferramentas da Astral
  • Estão previstos recursos como remoção de código morto, detecção de dependências não utilizadas, análise de alcançabilidade de vulnerabilidades de segurança (CVE) e linting com reconhecimento de tipos
• A Astral pretende melhorar continuamente o ty com o objetivo de tornar o Python o ecossistema de programação mais produtivo

Agradecimentos

• Dezenas de contribuidores de código aberto participaram do desenvolvimento do ty, que foi lançado sob a licença MIT
• Várias pessoas e equipes das comunidades Salsa, Elixir e Python typing forneceram colaboração técnica e inspiração
• A equipe principal da Astral desenvolveu o ty com base em uma compreensão profunda de teoria dos tipos, semântica de runtime do Python e padrões de uso do ecossistema

[iolothebard]

A Astral é fã de Python ou de Rust…
Bem astral mesmo~

[GN⁺]

Comentários no Hacker News

• Seria bom adicionar o Ty a esta tabela
  Olhando a tabela de resultados de conformidade de tipagem em Python, acho que não se deve subestimar o desempenho do Pyright
  Testei o Ty (LSP) rapidamente no Emacs e ele funciona bem. Só me incomoda um pouco que, ao exibir assinaturas de métodos, as anotações de tipo de alguns parâmetros parecem verbosas demais
  Ainda assim, acho provável que eu use o Ty no longo prazo. Parabéns pelo primeiro beta

  • Conformidade com a especificação é importante, mas eu não recomendaria escolher um verificador de tipos com base nisso
    Isso está distante do que os usuários reais consideram importante. (Eu mesmo criei a especificação e os testes no Python Typing Council)
  • Nós também vamos adicioná-lo à tabela em breve. Vai levar um tempo para alcançar o nível de conformance do Pyright, mas esse é o objetivo antes do lançamento oficial
  • O Pyright também é excelente, mas o BasedPyright é uma versão ainda melhorada dele
    Mesmo assim, sou um usuário satisfeito do uv e pretendo migrar quando o Ty estiver estável o suficiente
  • Este PR ainda está em WIP, mas me motivou a voltar a fazer contribuições OSS
  • O Pyright é bom, mas a velocidade é lenta. Como a responsividade do LSP tem grande impacto na UX, estou curioso para ver quanto o Ty melhorou

• Como a Astral está criando ferramentas excelentes, espero que ela cresça bem sem uma monetização destrutiva

  • O primeiro produto comercial da Astral é o pyx. Espero que tenha sucesso e permita que continuem criando ótimas ferramentas open source
  • Acho que o trabalho deles até agora está no nível de um serviço público para a comunidade Python
  • A direção parece bem parecida com a do bun
  • Só acho uma pena quando dizem que substituem completamente as ferramentas existentes, mas na prática ainda não implementam todos os recursos
    No fim, há casos em que é preciso voltar para as ferramentas antigas. Para mim, verificação de tipos correta é mais importante do que velocidade

• Obrigado à equipe da Astral. Usamos muito Pydantic, então estou animado em saber que o suporte de primeira classe está previsto para o lançamento oficial do Ty
  No momento, estamos rodando Pyright e Mypy juntos, mas parece redundante porque eles capturam erros diferentes
  Segundo esta tabela, o Pyright seria um superset, mas minha experiência foi diferente
  A análise é de dois anos atrás, então talvez hoje seja diferente. Tenho curiosidade se existe algum caso de unificação para apenas Pyright em uma base de código grande

  • Eu também, como usuário inicial do mypy, comparei quando o Pyright foi adicionado ao VS Code
    Em muitos casos o mypy inferia de forma mais flexível e precisa, e o Pyright gerava muitos false positives, a ponto de eu deixá-lo desativado
    Hoje em dia o Pyright deve ter melhorado bastante, mas o BasedPyright foi, ao contrário, improdutivo para mim
    Na comunidade há uma tendência forte de diminuir o mypy e exaltar o Pyright, mas minha experiência é um pouco diferente
  • Repetindo, os testes de conformidade com a especificação não refletem a experiência real do usuário
    Eles se concentram principalmente na semântica das anotações, então não são adequados como critério para escolher um verificador de tipos
    (Eu também criei essa especificação e esses testes no Python Typing Council)

• Acho que o título “Anúncio do lançamento beta do Ty” teria sido mais apropriado
  Eu preferia o Pyrefly ao Pyright, mas um bug recente me obrigou a fixar uma versão anterior, o que foi inconveniente
  Quando tentei instalar o Ty, apareceu um erro de compatibilidade de versão com o Cursor

  • Se houver alguma mensagem de erro adicional, por favor abra uma issue. Eu uso a extensão do Ty no Cursor há semanas sem problemas, então está difícil reproduzir
  • (Sou mantenedor do Pyrefly) Seria bom deixar esse crash como issue também no repositório do Pyrefly

• Ainda não entendo por que ainda existem tantos verificadores de tipos para uma única linguagem
  Quem cria bibliotecas precisa testar em todos os verificadores? Os desenvolvedores só devem usar bibliotecas que suportem um verificador específico?

  • Python é uma linguagem de duck typing + anotações de tipo opcionais, então é inevitável que surjam implementações variadas
  • Em parte, isso também vem das diferenças no alcance da inferência para quem chama ou nas políticas de exigência de tipos explícitos
    Nas fronteiras entre pacotes, tipos explícitos são necessários, mas no código interno há muita ambiguidade
    A Astral, em particular, está tomando o desempenho de processamento incremental como um objetivo central de projeto
  • Na prática, a maioria testa com base no mypy. O Pyright está ampliando gradualmente sua influência graças à extensão padrão do VS Code
    Se necessário, também é possível garantir compatibilidade fornecendo diretamente type stubs

• Gosto que o Ty adote a posição de que “não é preciso adicionar anotações para satisfazer o verificador de tipos”
  Verificadores anteriores incomodavam com avisos triviais, mas o Ty detecta bem erros lógicos reais

• Só hoje descobri que o Ty também atua como servidor de linguagem (LSP)
  Ou seja, ele pode substituir tanto o mypy quanto o Pyright no Neovim ou no VSCode

• Queria saber como está o suporte ao Django. O Django tem muito código mágico, então é difícil para verificadores de tipos lidarem com ele

  • O Ty ainda não oferece suporte ao Django e também não tem sistema de plugins
    Se você usa Django, é melhor continuar com mypy ou Pyright por enquanto

• Mesmo que o Ty não seja rápido, acho que só o suporte a tipos de interseção (A & B) já o torna útil
  É bom ver um recurso que fazia falta no sistema de tipos padrão do Python

• Fico me perguntando se existe algo como o uv para Ruby. Em Python ou TypeScript eu uso uv ou bun, mas o Ruby parece estar ficando para trás

  • Existe uma nova ferramenta de gerenciamento de Ruby chamada Rv. Talvez ela possa ser essa alternativa