Python 3.15 RC3 trava lazy imports e UTF-8 padrão: o que revisar antes de migrar sistemas legados

A terceira e última release candidate do Python↳Python56 conteúdosVSCode + Python + Alexa: Desenvolva e teste skills para alexa localmente com pythonDev (Back & Front) · out 2025Dominando decoradores em Python: um guia completo com exemplosDev (Back & Front) · jan 2025Desenvolvimento de software: diferenças entre Python, JavaScript e JavaGestão Dev & TI · nov 2024Ver tudo em Dev (Back & Front) → 3.15, divulgada nos últimos dias pela Python Software Foundation, adiou o lançamento final para 9 de outubro por causa de bugs de última hora nos lazy imports. Para quem mantém código em produção, a lista de mudanças que merece teste agora é mais longa do que parece.

O Python 3.15 entrou na reta final. O time de release publicou no blog oficial Python Insider a terceira release candidate da série, batizada de 3.15.0rc3, informando que o lançamento final, antes previsto para esta semana, foi adiado para 9 de outubro de 2026. O motivo: bugs de última hora ("last-minute lazy-import release blockers") considerados graves o suficiente para merecer mais uma rodada de testes antes de virar versão estável.

A RC3 reúne 156 correções, melhorias de build e ajustes de documentação feitos por 82 contribuidores desde a rc2. A partir daqui, a política do projeto é rígida: só entram mudanças que sejam correções de bug revisadas. Não há mais mudanças de ABI previstas para o resto da série 3.15. Ou seja, o que está na rc3 é, para efeitos práticos, o comportamento que vai para produção.

Por que o atraso importa mais que o atraso em si

O detalhe que interessa a quem mantém sistema legado não é o adiamento de uma semana, é o motivo dele. Os bugs que seguraram o lançamento final são ligados ao PEP 810, a feature de lazy imports explícitos que o Python 3.15 introduz para reduzir tempo de startup.

Lazy imports explícitos permitem declarar que um módulo só deve ser efetivamente carregado quando algum nome dele for usado pela primeira vez, em vez de no momento do import. Isso ataca um problema real de aplicações grandes: scripts CLI, Lambdas e processos de curta duração que pagam o custo de importar dezenas de dependências mesmo quando só usam uma fração delas.

O ponto de atenção é justamente esse: é uma mudança na ordem de execução do código, não só uma otimização silenciosa. Projetos que dependem de efeitos colaterais no momento do import (registro de plugins, inicialização de drivers de banco, configuração de logging) podem se comportar diferente se adotarem lazy imports sem revisar essas dependências implícitas. O fato de a própria equipe ter encontrado bugs de "última hora" nessa área reforça que não é feature para ativar por padrão em código de produção sem teste dedicado.

UTF-8 como padrão: o breaking change que passa despercebido

Outra mudança da série que pesa mais para quem mantém sistema antigo que para quem começa projeto novo é o PEP 686, que torna UTF-8 o encoding padrão do Python, substituindo a antiga dependência do locale do sistema operacional.

Em ambientes legados brasileiros, isso tem peso concreto:

• Scripts de ETL e processamento de arquivo que historicamente rodavam em servidores com locale pt_BR.ISO-8859-1 ou pt_BR.CP1252 podem ter decodificado texto errado sem erro nenhum até agora, porque o Python seguia o locale do sistema.
• Código que abre arquivo com open() sem especificar encoding= explicitamente é o principal candidato a mudar de comportamento.
• Testes que passam no ambiente de desenvolvimento (geralmente já em UTF-8) e falham em produção (servidor com locale legado) tendem a aparecer só depois do deploy.

Em resumo: se o sistema tem open() sem encoding explícito espalhado pelo código, essa é a mudança do 3.15 que merece um grep antes de qualquer outra coisa.

O que mais está na lista de mudanças da série

Além de lazy imports e encoding padrão, a nota de lançamento do Python Insider lista um conjunto de novidades que compõem o quadro completo do 3.15 frente ao 3.14:

O JIT experimental merece nota à parte: o ganho de 7 a 8% de média geométrica em Linux x86-64 e de 11 a 12% em macOS AArch64, segundo o anúncio, é medido contra o interpretador padrão (e contra o interpretador tail-calling, no caso do macOS). É compilador ainda experimental, não ativado por padrão, e a recomendação segue sendo tratá-lo como opt-in para quem quer testar performance, não como baseline de produção.

O que fazer com o RC3 agora

A nota de lançamento é direta sobre o papel da RC3: é preview, não é recomendada para produção, e o call to action é específico para quem mantém pacote publicado no PyPI.

Encorajamos fortemente os mantenedores de projetos Python de terceiros a preparar seus projetos para a versão 3.15 durante esta fase, e a publicar wheels do Python 3.15 no PyPI para estarem prontos para o lançamento final da 3.15.0.

We strongly encourage maintainers of third-party Python projects to prepare their projects for 3.15 during this phase, and publish Python 3.15 wheels on PyPI to be ready for the final release of 3.15.0.Equipe de release do Python 3.15 (Hugo van Kemenade, Ned Deily, Steve Dower)

Para quem mantém sistema legado (não biblioteca publicada), o roteiro equivalente é outro: rodar a suíte de testes contra a rc3 num ambiente isolado, grepar por open() sem encoding explícito, mapear import com efeito colateral antes de considerar lazy imports, e só então decidir o timing da migração. Como não há mais mudança de ABI prevista a partir daqui, qualquer wheel compilada contra a rc3 funciona com a versão final, o que reduz o risco de quem já está testando extensões em C.

Vale registrar também um aviso específico de plataforma: usuários de macOS 27.0 podem ver IDLE e outras aplicações tkinter travarem ao abrir diálogos de menu, por uma mudança de comportamento do sistema operacional que afeta o Tk em todas as versões atuais do Python, não só no 3.15. Quem depende de ferramentas baseadas em Tk nesse sistema deve acompanhar o issue #158053 no rastreador do CPython antes de atualizar o macOS.

Com a final marcada para 9 de outubro e congelamento de ABI já em vigor, o 3.15 está, na prática, definido. O que resta é o trabalho de quem mantém código rodando: separar o que é novidade de catálogo do que é mudança de comportamento silenciosa, e testar a segunda categoria antes que ela apareça como bug em produção.

Fonte: Python Insider