JIT do CPython será removido após a retirada da PEP 836

O compilador just-in-time (JIT) experimental do CPython, o interpretador padrão do Python, deve ser removido da branch main do projeto. Seus autores retiraram a PEP 836, a proposta que deveria tornar o JIT um recurso oficial, em 19 de outubro de 2026. O LWN.net informou em 26 de outubro que o código provavelmente sairá "relativamente em breve", idealmente no início do ciclo do Python 3.16. Isso encerra, por enquanto, o esforço para deixar o Python padrão mais rápido com um compilador embutido no interpretador.

Um JIT transforma código Python executado com frequência em código de máquina enquanto o programa roda. As builds oficiais do Python 3.15 para Windows e macOS incluem um como experimento, desativado por padrão.

Como se chegou até aqui

O gatilho foi um anúncio do Python Steering Council de 5 de junho de 2026, o grupo que governa a linguagem. Ele pediu uma proposta formal, chamada Standards Track PEP (Python Enhancement Proposal), defendendo o JIT como parte suportada do CPython.

O conselho definiu termos firmes:

Regra	Detalhe
Novo trabalho no JIT	Nenhum recurso novo, otimização ou trabalho de desempenho na main até que uma PEP seja aceita
Ainda permitido	Correções de bugs e de segurança
Prazo	Seis meses para enviar e resolver uma PEP
Se nenhuma PEP for aceita	"o código do JIT deve ser removido da branch main"
Python 3.15	O conselho estava "de acordo com o status quo para o 3.15"

O conselho disse que não achava que a equipe do JIT tivesse contornado o processo. Admitiu que ele próprio não tinha sido rigoroso o suficiente com o processo.

O que a PEP 836 propunha

Savannah Ostrowski, Ken Jin e Brandt Bucher escreveram a PEP 836, intitulada "JIT Go Brrr", voltada ao Python 3.16. Ela não pedia que o JIT fosse declarado suportado de imediato. Propunha um caminho com prazo limitado e metas mensuráveis.

• Com o GIL: a build com JIT pelo menos 5% mais rápida que o interpretador normal no primeiro ano. O GIL, ou global interpreter lock (trava global do interpretador), é a trava que só deixa uma thread executar código Python por vez.
• Free-threaded: pelo menos 20% mais rápida que o interpretador free-threaded até a primeira beta do Python 3.17.
• Mudança de design: passar do registro de traces do código mais executado para a compilação de métodos inteiros.

Segundo o LWN, o conselho respondeu em 21 de setembro. Disse que a PEP respondia às suas perguntas, embora algumas respostas fossem menos convincentes. Ainda assim, queria mais sobre segurança, suporte a plataformas e comportamento visível para os usuários. Chamou de "muito, muito tarde" uma revisão de compatibilidade planejada para o primeiro release candidate do 3.17.

Segundo o InfoWorld, o conselho também disse que faltavam à PEP detalhes sobre suporte de longo prazo, testes de desempenho e ferramentas de depuração. Chamou as metas de velocidade de otimistas demais.

Por que os autores desistiram

"Não sentimos que temos a disponibilidade pessoal para levar a versão atual adiante", escreveu Ostrowski, conforme citado pelo InfoWorld. "O Steering Council, com razão, estabelece um padrão alto para uma proposta desse escopo", acrescentou. A equipe ainda acredita "na direção técnica descrita na PEP", disse ela.

O LWN observa que Ostrowski é release manager do Python 3.16 e 3.17. A publicação da retirada dizia que o código de referência seria publicado e vinculado a partir da PEP.

Os ganhos foram reais, mas modestos. A PEP 836 relata uma aceleração de 4% a 12% na média geométrica no Python 3.15 nas principais plataformas. Segundo o InfoWorld, os ganhos ajudavam principalmente alguns tipos de programas, como loops intensivos de longa duração.

O que isso significa para desenvolvedores

A maioria dos usuários de Python nunca ativou o JIT, então o código do dia a dia não é afetado. Ainda assim, alguns grupos devem agir.

• O Python 3.15 não muda. O conselho aceitou o status quo para o 3.15. Se você define PYTHON_JIT=1 hoje, isso continua funcionando nessa versão.
• Não planeje contando com um JIT no 3.16. A remoção é esperada no início do ciclo do 3.16. Trate qualquer aceleração que você mediu no 3.15 como temporária.
• Builds mais simples pela frente. Builds com JIT precisam do LLVM, um kit de ferramentas de compilação, na hora do build. Equipes que compilam o Python a partir do código-fonte provavelmente poderão eliminar essa etapa mais tarde.
• Procure velocidade em outro lugar. O próprio conselho citou projetos JIT separados, como CinderX, Numba e PyTorch. Faça primeiro o profiling do seu código e depois escolha a ferramenta que se encaixa no caminho crítico.
• Forks podem continuar. Brett Cannon disse que parar o trabalho na main não o interrompe em outros lugares, segundo o LWN. Qualquer JIT revivido enfrentaria o mesmo padrão alto para voltar.

O Python 3.15.0 foi lançado em 9 de outubro com um JIT mais rápido como uma de suas principais novidades. Menos de três semanas depois, esse mesmo JIT não tem caminho para se tornar oficial.