Python 3.15 chega ao primeiro release candidate: o que testar antes da versão final

Python 3.15 entrou na fase release candidate. Veja o que conferir em dependências e testes antes de adotar a versão final.

Ilustração editorial de um símbolo de comando em vidro verde-água sobre módulos de software.

Ilustração editorial gerada com IA para o Papo de Prompt.

O Python 3.15 entrou na fase de release candidate em 4 de agosto de 2026. Isso significa que o conjunto de recursos está fechado e que, até a versão final prevista para 1º de outubro, apenas correções revisadas devem entrar no código.

Para equipes de desenvolvimento, o RC1 não é um convite para atualizar servidores de produção. É a janela certa para testar aplicações, bibliotecas e imagens de contêiner enquanto ainda existe tempo para relatar incompatibilidades.

O que muda na fase release candidate

Segundo a Python Software Foundation, não devem ocorrer novas mudanças de ABI na série 3.15 a partir deste ponto. Wheels binários compilados contra os candidatos podem ser compatíveis com a versão final, reduzindo o trabalho de mantenedores que precisam preparar pacotes para o lançamento.

A própria equipe do Python ainda classifica o RC1 como prévia e não recomenda seu uso em ambientes de produção. O foco deve ser compatibilidade: executar testes, observar alertas de depreciação e verificar extensões nativas.

Recursos que merecem atenção

  • Imports preguiçosos explícitos: a PEP 810 abre espaço para reduzir tempo de inicialização sem esconder completamente quando um módulo é carregado.
  • Tipos nativos: frozendict e sentinel passam a atender casos antes resolvidos com implementações próprias.
  • Observabilidade: frame pointers ativados por padrão facilitam o uso de ferramentas de profiling do sistema.
  • Free threading: o trabalho de estabilização da ABI continua tornando a execução sem GIL mais previsível para extensões.
  • Codificação UTF-8: o novo padrão reduz diferenças de comportamento entre sistemas, mas merece teste em aplicações que dependem da codificação local.

Como testar sem colocar o projeto em risco

  1. Crie um job separado no CI usando Python 3.15 RC1 e permita falha apenas durante a primeira rodada de diagnóstico.
  2. Execute testes unitários, integração e comandos de lint, registrando mudanças de comportamento.
  3. Recompile dependências com extensões em C ou Rust e verifique a disponibilidade de wheels.
  4. Teste imagens Docker, ferramentas de empacotamento e ambientes virtuais do zero.
  5. Relate regressões reproduzíveis ao projeto responsável antes de criar soluções locais permanentes.

A leitura do Papo de Prompt

A notícia relevante não é apenas que uma versão nova está perto. O release candidate transforma a atualização em uma tarefa concreta de engenharia. Quem testa agora reduz a chance de descobrir incompatibilidades quando a versão final já estiver circulando.

Fontes

Resumo da semana

Leve contexto para a caixa de entrada.

Uma edição semanal, sem barulho e sem promessas vazias.