Python Language Summit 2026 debate Rust e um novo GC

A Python Software Foundation publicou em 30 de setembro seus relatos do Python Language Summit 2026. O summit é onde os desenvolvedores do núcleo do Python discutem o futuro da linguagem antes que algo vire uma proposta formal. Um dos planos mais concretos veio da equipe Rust for CPython: levar o Rust ao CPython, o principal interpretador Python, passo a passo.

O resumo da PSF conta que 47 desenvolvedores do núcleo e convidados se reuniram em 14 de julho de 2026 em Cracóvia, na Polônia, durante a EuroPython 2026. Eles assistiram a 10 palestras completas e 5 palestras relâmpago. Foi o primeiro summit na Europa desde Florença, em 2011. "Daqui em diante, o Python Language Summit vai se alternar a cada ano entre a PyCon US e a EuroPython", escreve a PSF. Seth Larson escreveu os relatos, e o LWN os indicou aos leitores no mesmo dia.

O Rust passa de experimento a plano

David Hewitt falou em nome da equipe Rust for CPython, liderada por Kirill Podoprigora e Emma Smith, com cerca de 60 desenvolvedores. A equipe quer adicionar Rust ao CPython aos poucos, começando por módulos pequenos e independentes.

O primeiro candidato é o zlib, o módulo de compressão, construído sobre a biblioteca zlib-rs. O relato do Python Insider cita a equipe dizendo que o zlib-rs é "mais rápido que o zlib e o zlib-ng em muitas plataformas". O argumento a favor do Rust é a segurança. As issues com o rótulo type-crash do CPython subiram de 82 em 2021 para uma previsão de 353 em 2026.

As fases do plano cobrem o Python 3.16 em outubro de 2027, o 3.17 em outubro de 2028 e o 3.18 em 2029 ou depois. O suporte do Rust nas diferentes plataformas agora é "cada vez menos uma preocupação", diz a equipe. Hewitt também foi direto sobre o estado final: "seria desonesto dizer que o Rust seria opcional para sempre". O CPython vai continuar sendo "um projeto de duas linguagens por um bom tempo".

Um novo plano para a coleta de lixo

Mark Shannon disse que a coleta de lixo, o trabalho de encontrar e liberar memória que não é mais usada, ocupa cerca de 11,67% do tempo de execução do Python. Ele propôs um híbrido de dois projetos. Um coletor geracional verifica os objetos novos com mais frequência, porque "a maioria dos objetos morre jovem". Um coletor incremental faz o trabalho em pequenas fatias, em vez de uma parada longa.

O motivo são os tempos de pausa. Shannon estimou as pausas incrementais em "dezenas de milissegundos", contra cerca de 3 segundos na abordagem geracional. No projeto dele, a geração jovem começa com 20 MB. A sala discordou em um ponto: se o Python deve oferecer ajustes no estilo do Java para afinar o coletor.

Depois do free-threading: um modelo de concorrência mais seguro

O free-threading é a nova versão do Python que consegue rodar threads de fato em paralelo. Tobias Wrigstad, Fridtjof Stoldt e Donghee Na perguntaram o que vem depois. Eles propuseram o Behavior-Oriented Concurrency, um modelo em que as tarefas declaram de quais dados precisam antes de rodar.

Cada dado compartilhado fica em um "cown", abreviação de concurrent owner, que só uma tarefa pode usar por vez. Um decorador @when indica os cowns de que uma tarefa precisa. Segundo os palestrantes, esse projeto evita deadlocks e condições de corrida. Uma prova de conceito, o bocpy, já roda no Python estável usando subinterpretadores. O summit não apoiou nenhuma abordagem específica e preferiu mais pesquisa.

Tipagem, um namespace std e inicialização mais rápida

Palestra	Palestrante	A ideia
PEP 827, manipulação de tipos	Michael J. Sullivan	Tipos que calculam outros tipos, como derivar de um só modelo os tipos ORM de criação e atualização
Namespaces	Pablo Galindo Salgado	Um namespace std de primeiro nível, para que import std.json sempre signifique a biblioteca padrão
Snapshots de memória	Hood Chatham	Salvar um interpretador já iniciado e restaurá-lo, o que corta o "Hello, world" do Pyodide de 1,406 s para 0,353 s
Suporte ao macOS	Ned Deily	Incluir o macOS na PEP 11, a política de suporte a plataformas, e modernizar um instalador com 25 anos de dívida técnica

Sullivan ressaltou que "os usuários não devem escrever tipos como esses, ou só muito raramente". Galindo Salgado prometeu que o velho import json continuaria funcionando: "Não podemos quebrar o mundo, isso seria ruim." O principal risco dos snapshots é a segurança. Uma semente de hash que deveria ser aleatória a cada execução ficaria congelada e compartilhada.

O que isso significa para desenvolvedores

Nada aqui está decidido ainda. O summit é uma discussão, e cada mudança ainda precisa de uma PEP, o processo formal de propostas do Python. Leia esses relatos como um mapa de para onde as próximas versões estão indo.

Se você compila o CPython a partir do código-fonte, comece a verificar a questão do Rust. Isso inclui distribuições Linux, placas embarcadas e plataformas incomuns. As próprias palavras de Hewitt dizem que o Rust não vai continuar opcional para sempre. Confirme que existe uma cadeia de ferramentas Rust para cada plataforma em que você publica, antes que o módulo zlib torne isso importante.

Pare de dar a arquivos locais nomes de módulos da biblioteca padrão. Um arquivo chamado json.py ou random.py no seu projeto já pode esconder o módulo real hoje. O namespace std pretende resolver esse problema, mas bons nomes resolvem agora.

Se o seu serviço sofre com pausas longas da coleta de lixo, acompanhe o trabalho de Shannon. Não monte ajustes em cima disso ainda, porque o summit não chegou a um acordo sobre oferecer ajustes.

Autores de bibliotecas devem ler a PEP 827. Mantenedores de ORMs e frameworks são o público dela. Desenvolvedores de aplicações vão se beneficiar, na maior parte, sem escrever esses tipos.

Experimente o bocpy se você escreve Python concorrente. Ele roda no Python de hoje, e o retorno agora influencia o que a equipe do núcleo vai decidir construir.