Python em outubro: a compatibilidade quebra além do interpretador

O lançamento final do Python 3.15 foi reagendado de 01/10/2026 para 09/10/2026; a 3.15.0rc3 saiu em 02/10/2026 após correções, incluindo bloqueadores nos imports preguiçosos.[13] O panorama da Real Python também reúne mudanças em bibliotecas de dados, empacotamento e contratos de APIs de IA.[13] Para aplicações existentes, a prioridade é descobrir quais pressupostos deixam de valer, não apenas acompanhar o calendário.

O que muda para quem desenvolve

Python 3.15 passa a usar UTF-8 como padrão, e o artigo recomenda habilitar EncodingWarning e convertê-lo em erro de teste para encontrar chamadas sem encoding explícito.[13] A migração precisa incluir arquivos realmente codificados em formatos legados.[13] Minha proposta é tratar encoding como parte do contrato de entrada e saída, não como preferência da máquina que executa o código.

SQLAlchemy 2.1.0 exige Python 3.11 ou posterior; greenlet deixa de vir por padrão e aplicações assíncronas precisam do extra sqlalchemy[asyncio].[13] URLs postgresql:// passam a selecionar psycopg 3, enquanto oracle:// passa a selecionar oracledb.[13] Uma atualização pode, portanto, alterar dependências e driver sem uma grande mudança visível no código da aplicação.

Polars 2.0 ainda está em release candidate e torna streaming padrão para consultas LazyFrame.[13] A matéria alerta para não depender da ordem incidental de linhas em agrupamentos, joins e unpivots, recomendando ordenação explícita ou maintain_order=True quando necessário.[13] Se a ordem faz parte da resposta prometida ao consumidor, ela deve entrar no teste.

Nos serviços de IA, a Assistants API da OpenAI foi encerrada em 26/08/2026, exigindo migração para Responses e Conversations.[13] GPT-6 Astra exige Responses para ferramentas e rejeita valores personalizados de temperature e top_p.[13] Claude Fable 5.1 e Mythos 5.1 rejeitam tool_choice com any ou tool; a alternativa citada, auto com uso estrito, não obriga a realização de uma chamada.[13]

Como aplicar

Monte uma matriz por componente: versão atual, versão candidata, contrato que pode mudar e teste capaz de detectar a diferença. Mantenha o ambiente de produção separado da avaliação do candidato do interpretador e fixe as dependências usadas em cada execução.

Para arquivos, inclua amostras UTF-8 e legadas com resultado esperado conhecido. Para bancos, teste conexão, transação e uma consulta pelo driver realmente selecionado. Para dados, compare conjuntos e ordem separadamente, exigindo ordenação apenas onde ela faz parte do contrato.

Nas integrações de IA, faça chamadas mínimas por capacidade: resposta textual, chamada de ferramenta e tratamento de erro. Teste também uma resposta sem ferramenta quando o fluxo permite auto. Evite que a lógica de negócio dependa de parâmetros aceitos por um modelo e rejeitados por outro.

Separe essas mudanças em entregas pequenas. Se trocar interpretador, biblioteca e provedor ao mesmo tempo, a investigação de uma regressão terá mais hipóteses concorrentes. O ganho operacional vem de conseguir localizar a quebra e reproduzi-la.

Cuidados e limites

Os ganhos publicados de JIT dependem da plataforma e do build; o JIT experimental não fica habilitado em qualquer distribuição apenas pelo lançamento.[13] Polars 2.0 continua candidato, e o ganho aproximado de cinco vezes citado para streaming é uma alegação dependente da carga.[13]

O artigo recomenda testar em isolamento, aguardar wheels das dependências compiladas e considerar a 3.15.1 para produção.[13] Isso não constitui um prazo obrigatório para todo projeto. O aceite deve depender da sua matriz de compatibilidade e da disponibilidade dos componentes que a aplicação realmente usa.

Fonte

[13] Fonte: Real Python