Pyrefly - um novo verificador de tipos e experiência de IDE para Python

• O Pyrefly da Meta é um verificador de tipos para Python de código aberto e uma extensão para IDE desenvolvida em Rust
• Oferece análise ultrarrápida e recursos de integração com IDE, tendo sido criado para superar as limitações do Pyre
• Adota como princípios a inferência automática de tipos, o suporte a bases de código grandes e a filosofia de código aberto
• Busca melhorar o sistema de tipos em todo o ecossistema por meio de colaboração e contribuições com a comunidade Python
• A versão alfa já foi lançada, e a equipe está pedindo ativamente feedback e contribuições da comunidade

---

Introdução

• Pyrefly é um projeto open source da Meta, desenvolvido em Rust, que funciona como verificador estático de tipos para Python e extensão de IDE
• Ajuda na detecção prévia de erros ao verificar a consistência de tipos antes da execução do código
• Pode ser usado tanto com integração em IDE quanto via CLI, oferecendo um fluxo de trabalho flexível
• Tem como objetivo contribuir para a evolução do sistema de tipos do Python e de várias bibliotecas por meio da colaboração com a comunidade open source

Contexto do desenvolvimento do Pyrefly

• Em 2017, a Meta desenvolveu um novo verificador de tipos, que mais tarde se tornou o Pyre, para a grande base de código Python do Instagram
• O Pyre foi desenvolvido em OCaml com foco em desempenho, inspirado em projetos de design robusto como Hack e Flow
• Com o passar do tempo, surgiram limitações à medida que cresciam as necessidades de evolução do sistema de tipos e de integração com IDE
• Ferramentas da comunidade, como o Pyright, também foram usadas, mas havia limitações para atender requisitos como navegação em bases de código muito grandes e exportação de tipos, o que levou à criação do Pyrefly

Princípios principais do Pyrefly

• 1. Desempenho

  • Desenvolvedores precisam de verificação de tipos rápida a cada tecla digitada logo após escrever o código
  • O Pyrefly tem uma arquitetura em Rust de alto desempenho capaz de verificar 1,8 milhão de linhas por segundo mesmo em bases de código extremamente grandes

• 2. Projeto centrado em IDE

  • As abstrações foram projetadas desde o início para que IDE e CLI mantenham a mesma visão
  • No Pyre isso foi uma adaptação posterior, mas no Pyrefly a consistência foi enfatizada desde a fase de projeto

• 3. Inferência

  • Suporta inferência automática de tipos mesmo em código Python sem anotações e sem tipos explicitamente declarados
  • Exibe no IDE os tipos de valores de retorno e variáveis locais e, para ajudar a escrever código melhor, permite inserir automaticamente o tipo inferido com duplo clique

• 4. Código aberto

  • O Pyrefly está disponível no GitHub sob licença MIT, e PRs e relatos de issues da comunidade são bem-vindos
  • Busca comunicação ativa por meio de um canal no Discord e integração com o ecossistema Python e bibliotecas importantes da Meta, como o PyTorch

O futuro do Pyrefly

• A equipe está trabalhando com a comunidade para melhorar a linguagem Python e a experiência do desenvolvedor
• Desde o início do desenvolvimento do Pyre, a Meta manteve o código aberto e contribuições para PEPs, e com o Pyrefly pretende maximizar os benefícios do uso de tipos para diversos desenvolvedores, bibliotecas e iniciantes
• Com base em sua experiência e resultados no uso de tipos em linguagens dinâmicas, a Meta pretende compartilhar várias experiências e promover a melhoria da qualidade dos tipos no ecossistema
• Atualmente o Pyrefly está em versão alfa, mas segue recebendo correções de bugs e novos recursos com meta de lançamento oficial neste verão
• O feedback da comunidade é muito importante, e a equipe pede ativamente relatos de issues e solicitações de melhoria após o uso do Pyrefly

Uso da versão alfa do Pyrefly e informações da comunidade

• O processo de desenvolvimento do Pyrefly e seus detalhes técnicos foram apresentados no Meta Tech Podcast e em palestras da PyCon US
• Mais novidades são divulgadas por vários canais, como sites relacionados ao Meta Open Source, YouTube, Facebook, Threads, X e LinkedIn

[GN⁺]

Comentários no Hacker News

• Em nome do "Python Language Tooling Team" da Meta, isso gera uma certa preocupação; com a popularidade enorme do uv, dá a sensação de que o ty pode acabar vencendo nesse espaço. Se der errado, pode surgir uma situação como Atom ou Flow, em que uma equipe interna acaba sendo superada por um projeto open source externo e, de cima, começa a surgir um clima de "será que essa equipe é mesmo necessária? vamos transformar isso em open source". Parece ser algo com que a gerência (Aaron Pollack?) deveria se preocupar.
  • Kevin, prazer em falar com você. Trabalhei no Flow no passado e hoje estou na equipe do Pyrefly. Desta vez adotamos uma abordagem diferente da do Flow e definimos claramente como prioridade o open source e a construção de comunidade. Houve bastante volatilidade recentemente em relação aos investimentos de infraestrutura das empresas, mas acredito que, neste momento, estamos no ponto de partida certo dessa jornada. Torcendo por vocês.
  • A Meta valoriza muito, em especial, o controle sobre projetos open source de ferramentas de desenvolvimento. No passado, houve um caso em que o mantenedor do git apontou questões sobre o uso de monorepo e recusou upstream uma melhoria, o que levou à migração para o Mercurial; do lado do Mercurial, as contribuições foram aceitas com boa vontade. Como as ferramentas internas mudam muito rapidamente, faz sentido possuir os próprios projetos.
  • Das coisas que saíram do Facebook, JSX é a minha favorita (talvez a única parte que eu realmente ache boa).
• Trabalho na equipe do Pyrefly na Meta. O FAQ cobre muitas dessas perguntas, então deixo aqui o link para referência. Também posso responder a outras dúvidas; obrigado pelo interesse.
• Ultimamente surgiram três type checkers de Python escritos em Rust (Microsoft, Facebook, Astral), enquanto o mypy continua existindo.
  • Correção: o type checker da Microsoft, o Pyright, é baseado em TypeScript. Mesmo assim, pela minha experiência, ele ainda é mais rápido que o mypy.
  • São todos type checkers estáticos? Não há nenhum para runtime.
• Este é o anúncio oficial, mas o Pyrefly já tinha sido discutido algumas semanas atrás. No momento, ele está sendo lançado em fase alfa, com foco em corrigir bugs e desenvolver funcionalidades, e a meta da equipe é tirar o rótulo de alfa no verão.
• O código Rust mostrado aqui é muito fácil de entender, mas me preocupa ver ferramentas de Python sendo cada vez mais escritas em Rust; dá a sensação de mais um problema de N linguagens. Espero que o Mojo consiga fazer algo a respeito.
  • No ecossistema Python, o fluxo natural é usar Python onde ele dá conta e usar linguagens como Rust ou C onde alto desempenho é necessário. No fim, N=3 (Python, Rust e C), embora eu espere que o C desapareça gradualmente da programação de aplicações no longo prazo. Na prática, isso provavelmente vai levar muito tempo; talvez o próprio Python vire legado antes disso.
• Fico feliz em ver instruções de integração com Vim/Neovim, com link relacionado.
• Não entendo por que o fato de ter sido escrito em Rust é mencionado como uma grande vantagem. A maioria das pessoas não está executando um type checker em sistemas embarcados ou serviços de missão crítica; passa uma sensação parecida com "escrito em Erlang". Para código em que desempenho não é importante, escrever em Python permitiria mais participação e expansão da comunidade. Por que essa fixação em Rust?
  • Compartilhando minha experiência com Rust: do ponto de vista do usuário, há as vantagens de velocidade e segurança; do ponto de vista do desenvolvedor, é mais fácil contribuir. Acho que parte do apelo da Astral é justamente trazer essas ferramentas baseadas em Rust para Python. Conheço Python melhor do que Rust, mas sinto que é mais fácil contribuir para projetos em Rust. Minha visão é que portar ferramentas de qualidade do Rust para Python é o objetivo mais amplo.
  • Acho que LSP (Language Server Protocol) é exatamente o tipo de código em que desempenho importa muito. Isso afeta diretamente a responsividade da IDE. Rust é excelente tanto em CPU quanto em memória. Se fosse escrito em OCaml, Reason, Haskell etc., velocidade e eficiência provavelmente seriam suficientes, mas o grupo de possíveis contribuidores seria muito mais limitado.
  • Gosto de poder buscar por "[descrição da ferramenta] rust" e encontrar facilmente software com bom desempenho. Cerca de 95% das ferramentas que uso foram escritas em Rust, e estou satisfeito com quase todas.
  • Rust virou quase uma abreviação para "perceptivelmente rápido". E, por ser Rust open source, ainda dá para revisar o código.
  • Um type checker escrito em Python não oferece desempenho suficiente. Por exemplo, linters feitos em Python, como o Pylint, às vezes verificam uma coisa por linha de código e levam mais de 30 segundos; é uma área em que desempenho realmente importa.
• Tenho curiosidade sobre a transição de Pyre para Pyrefly e sobre a reescrita completa em Rust. Gostaria de saber quais benefícios concretos ou motivações houve nessa mudança de uma linguagem menos conhecida para o Rust, que está em alta.
  • Essa pergunta é tratada no nosso FAQ. Quando tivermos acumulado mais experiência, também gostaríamos de falar sobre isso em um post longo no blog. Segue o link.
• Parece um projeto tentando resolver coisas demais de uma vez.
• Perdi o interesse quando vi VS Code. Não entendo por que as pessoas acham que VS Code é uma IDE adequada para Python, quando existe uma IDE de verdade como o PyCharm.
  • O pyrefly não está preso só ao vscode. Seria bom ter um pouco mais de consideração pelo fato de que pessoas diferentes têm preferências diferentes. O pycharm também não é objetivamente melhor. Para mim, o desenvolvimento remoto no vscode é conveniente, e eu não teria vontade de ir à internet dizer que o pycharm é ruim.