O JIT experimental do Python será removido

Artigo original ↗ Discussão no Hacker News ↗

Os desenvolvedores principais do Python decidiram remover o compilador experimental just-in-time (JIT) do CPython, citando manutenção de longo prazo incerta, ganhos modestos no mundo real e a complexidade que ele adiciona a um runtime amplamente usado e sensível à segurança. Os comentaristas se dividem entre ver isso como uma governança saudável que protege a estabilidade e a compatibilidade com ferramentas, e como uma burocracia sufocante que torna quase impossível aprovar trabalho ambicioso de desempenho na implementação principal. Muitos apontam alternativas como PyPy, GraalPy, Cython, Numba ou reescritas completas em linguagens mais rápidas, ao mesmo tempo lamentando que as peculiaridades do ecossistema Python e da API C tornem especialmente difícil combinar a popularidade da linguagem com desempenho de ponta.

Reação geral à remoção do JIT

  • Muitos expressam decepção; esperavam que o JIT acelerasse de forma significativa o “Python puro” e reduzisse a necessidade de reescritas em Cython/Rust.
  • Outros veem a decisão como razoável, dado o ganho de velocidade modesto (frequentemente citado em torno de ~10%) em comparação com a grande complexidade e o custo de manutenção.
  • Alguns veem isso como mais uma tentativa fracassada de JIT para Python (depois de Psyco, Unladen Swallow, etc.), reforçando o pessimismo sobre o CPython algum dia obter um JIT sólido no repositório principal.

Processo, governança e “burocracia”

  • Um grupo argumenta que o processo de comitê e os requisitos rígidos de PEP mataram um experimento promissor, citando exigências “veneno‑pilha” como amplo suporte a ferramentas e métricas de sucesso.
  • Outro grupo argumenta que o processo funcionou como esperado: uma vez que algo vive em main, precisa ter escopo claro, plano de manutenção e história de compatibilidade; experimentos em aberto não pertencem ao núcleo de uma linguagem de infraestrutura global.
  • Há discordância sobre se isso é “burocracia” ou apenas governança necessária para um ecossistema maduro.

Desafios técnicos de um JIT para Python

  • A extrema dinamicidade do Python é citada como um problema central: __dict__, reatribuição de __class__, monkey-patching, metaprogramação, reescrita de bytecode pelo pytest, extensões C e APIs de introspecção complicam a otimização.
  • Alguns argumentam que isso não é fundamentalmente mais difícil do que a semântica de JavaScript ou Ruby e que JITs bem-sucedidos (V8, LuaJIT, PyPy, GraalPy) mostram que isso é viável com investimento suficiente.
  • Outros observam que a API C do CPython vaza detalhes de implementação, tornando mudanças profundas como JIT e remoção do GIL especialmente arriscadas.

Desempenho hoje e alternativas existentes

  • Opções frequentemente mencionadas: extensões C, Cython, Numba, mypyc, PyPy, GraalPy, Rust (via PyO3) e reescritas em Go.
  • Críticas: essas opções são fragmentadas, cada uma com limitações (atraso em relação às versões, problemas com a API C, subconjuntos restritos, complexidade de implantação). Muitos ainda querem “apenas um CPython mais rápido”.
  • Alguns argumentam que o Python atingiu limites práticos: se desempenho é um requisito central, a resposta é reescrever os caminhos críticos ou sistemas inteiros em linguagens mais rápidas, possivelmente com assistência de IA.

Preocupações de segurança e confiabilidade

  • Alguns apoiam evitar um JIT devido ao histórico de segurança em engines de JS e PHP; valorizam a VM de bytecode mais simples do CPython e sua contagem relativamente baixa de CVEs.
  • Outros respondem que o Python raramente executa código não confiável, então os riscos específicos de exploração de um JIT são menos convincentes do que os problemas de segurança já introduzidos por extensões C.

Direções alternativas e subconjuntos

  • Vários sugerem que um subconjunto mais estrito e tipado de Python com AOT/JIT (por exemplo, “Static Python”, algo no estilo Mojo, ou CinderX) pode ser o único caminho sustentável para grandes ganhos de velocidade.
  • Há ceticismo de que tal subconjunto possa ser padronizado sem enorme discussão interminável sobre bikeshedding, dada a cultura do Python e os recursos dinâmicos já existentes.