O JIT foi incluído, mas a aprovação não veio
O compilador JIT experimental do Python chegou ao CPython 3.13 como um recurso opcional, a partir de um trabalho iniciado no fim de 2023 e no início de 2024. O desenvolvedor core Brandt Bucher fez inicialmente o merge do copy-and-patch JIT, com a intenção de melhorar o desempenho em tempo de execução.
No entanto, o JIT nunca obteve aprovação formal e de longo prazo. Ele foi lançado sob a PEP 744, uma PEP Informational que apenas descrevia o recurso, e não uma PEP Standards Track, que teria consolidado seu lugar e o compromisso com a manutenção contínua. Essa lacuna processual deixou seu futuro incerto desde o início.
Não se tratou de uma reversão motivada por bugs; o código em si funcionava. Em vez disso, o projeto Python permite que recursos experimentais sejam lançados sem um compromisso permanente, criando um espaço para inovação que não sobrecarrega automaticamente a equipe principal com suporte por tempo indeterminado. A remoção do JIT decorre dessa falta de consenso formal, e não de uma falha técnica.
O Python Steering Council acabou impondo um ultimato: obter uma PEP Standards Track ou o JIT seria removido. Essa medida reforçou que, embora lançar código experimental seja uma coisa, convencer a comunidade e os mantenedores a comprometer recursos por tempo indeterminado é um desafio muito maior no desenvolvimento de código aberto.
O conselho pediu provas, não promessas
O steering council do Python, pouco impressionado com a introdução informal do JIT, emitiu um ultimato em junho de 2026: apresentar e aprovar uma proposta Standards Track em até seis meses, ou o código do JIT experimental seria removido da branch main. Não era uma sugestão; era um prazo rígido para um recurso que havia contornado a governança padrão.
Em resposta, Savannah Savannah Ostrowski, Ken Jin e Brandt Bucher enviaram a PEP 836, intitulada de forma apropriada "JIT Go Brrr: The Path to a Supported JIT Compiler for CPython", em julho de 2026. A crítica de 10 pontos do conselho foi rápida e implacável. Eles criticaram a PEP por dar atenção insuficiente à segurança, rotulando-a como “área negligenciada”, e descartaram suas projeções de desempenho e de impacto para os usuários como “excessivamente otimistas”.
Talvez a rejeição mais contundente tenha sido a da revisão de compatibilidade proposta, prevista para o release candidate do Python 3.17 em agosto de 2028. O conselho considerou esse cronograma “tarde demais, muito tarde mesmo”, ressaltando sua exigência de garantias imediatas e sólidas. Sem um roteiro convincente, o futuro do JIT parecia cada vez mais sombrio, apesar da promessa inicial.
Uma proposta promissora ficou sem pessoas
O ultimato do Python Steering Council pesou, mas uma proposta promissora não conseguiu se firmar. Em 19 de outubro de 2026, Savannah Savannah Ostrowski, release manager do Python 3.16 e 3.17, retirou formalmente a PEP 836, a proposta “JIT Go Brrr” que pretendia elevar o JIT ao status de standards-track. O motivo declarado: a evidente falta de “disponibilidade pessoal para levar a versão atual adiante”.
Isso não foi uma declaração de que os JITs seriam inúteis; muito pelo contrário. Savannah Ostrowski e sua equipe continuavam convencidos do potencial da tecnologia para melhorar o desempenho do Python. A retirada refletiu o enorme esforço técnico e político necessário para atender às rigorosas exigências do conselho, que incluíam tratar de preocupações de segurança e demonstrar ganhos de desempenho mais consistentes do que os modestos 4–12% de aceleração em média geométrica observados em benchmarks restritos.
O feedback do conselho foi direto, chamando a segurança de “área negligenciada” e considerando a revisão de compatibilidade proposta para agosto de 2028, no Python 3.17, “tarde demais, muito tarde mesmo”. Sem recursos dedicados para tratar esses pontos de forma abrangente, a PEP 836 não pôde prosseguir. Para contexto sobre a introdução inicial e menos formal do JIT, veja PEP 744 – JIT Compilation.
A consequência agora é praticamente certa: o código do JIT experimental será removido da branch main do CPython no início do ciclo de desenvolvimento do Python 3.16. A breve incursão do Python em um JIT integrado ao repositório parece ter chegado ao fim, vítima das realidades do código aberto, em que lançar código costuma ser a parte mais fácil.
Gostando do artigo? Receba um assim na sua caixa de entrada toda manhã.
um e-mail por dia · cancele em dois cliques · sem rastreadores de terceiros
O verdadeiro gargalo é a responsabilidade de longo prazo
Fazer o merge do código é o começo, não o fim, do desenvolvimento de código aberto. A remoção iminente do JIT da branch main do CPython ilustra uma lição crucial: a responsabilidade vai além dos commits iniciais. Os mantenedores assumem a responsabilidade contínua por revisões de segurança, riscos de compatibilidade, custos de memória e suporte de longo prazo, um fardo que a equipe do JIT, apesar de acreditar na tecnologia, não conseguiu sustentar.
Esse resultado não deve ser interpretado como a interrupção dos esforços de desempenho do Python. O JIT era um recurso experimental e opcional. Boa parte dos ganhos recentes de velocidade do CPython, incluindo as melhorias substanciais no Python 3.11 e no 3.12, veio do specializing adaptive interpreter, uma estratégia de otimização distinta e que continua em andamento.
Além disso, essa decisão não representa o fim do desenvolvimento de JIT para Python como um todo. Projetos alternativos como PyPy, Numba e PyTorch Inductor continuam a utilizar a compilação JIT. Essas soluções, voltadas a cargas de trabalho e ambientes de execução diferentes, operam fora da trilha de desenvolvimento principal do CPython, o que demonstra que o conceito de JIT continua relevante para determinadas aplicações Python de alto desempenho.
Perguntas frequentes
Por que o CPython está removendo seu JIT experimental?
O JIT não tinha uma PEP Standards Track aprovada, enfrentava preocupações de segurança e compatibilidade não resolvidas, e seus mantenedores não conseguiram assumir o tempo necessário para levar a proposta adiante.
O JIT foi removido por ter bugs?
Não. A decisão baseou-se em governança, manutenção de longo prazo, revisão de segurança e na questão de se os benefícios esperados justificavam os custos.
Qual era a diferença entre a PEP 744 e a PEP 836?
A PEP 744 documentou o JIT experimental, mas era informativa. A PEP 836 buscava a aprovação formal de um JIT suportado, mas seu autor principal a retirou.
Isso significa que o Python nunca terá um JIT?
Não. A decisão diz respeito ao JIT na branch main do CPython; projetos independentes e propostas futuras ainda podem buscar a compilação JIT.