Python Workers chega à disponibilidade geral na Cloudflare com debates sobre cold starts e manutenção

"Há uma diferença significativa entre financiar uma contribuição para um projeto upstream e financiar os mantenedores upstream."

Isso aparece claramente na postura do urllib3. O backend Emscripten permanece experimental lá e está explicitamente fora do escopo da política de segurança do projeto. Ele aponta para CVE-2025-50182, onde os controles de redirecionamento do urllib3 não se comportavam como esperado uma vez que requisições eram roteadas através de fetch, e alerta que pode haver mais diferenças desse tipo, porque a semântica de rede do navegador difere da usual do urllib3.

Cold starts: Syrus Akbary, fundador da Wasmer (plataforma WebAssembly concorrente), retomou preocupações que havia levantado no lançamento original. Ele mencionou que uma aplicação Python mínima inicia em cerca de 60ms no Wasmer Edge contra cerca de 900ms no Cloudflare Workers, segundo um benchmark publicado por sua empresa. Perguntou pelos números de p50 e p95 atuais, com e sem pacotes nativos.

Dominik Picheta, um dos autores do post da Cloudflare, respondeu:

"Nossa implementação de memory snapshot melhorou significativamente os cold starts."

Ele adicionou que sharding reduz a frequência com que cold starts ocorrem e apontou para um post anterior contendo números. O follow-up de Akbary notou que o post relatava um tempo de inicialização de cerca de 1,027 segundos e perguntou se tinha sido remeasurado desde então.

Acoplamento de versão: A outra objeção de Akbary foi estar preso às versões de Python e Pyodide que o workerd embutido usa. Picheta respondeu que flags de compatibilidade selecionam entre Python 3.12, 3.13 e 3.14, mas ressalvou que versões antigas trazem versões mais antigas do Pyodide com fewer features, incluindo JSPI. Akbary interpretou isso como confirmação do problema, já que a flag move workerd também.

Memória: Um comentário separado de dangoodmanUT levantou preocupações (sem testar), sugerindo que Python provavelmente consome "dezenas de MBs a mais" na alocação de memória do worker.

Debates técnicos

Uma troca solucionou um ponto técnico em vez de comercial. Akbary argumentou que patchear o event loop de Python para usar o loop JavaScript cria incompatibilidade, já que os dois diferem em quando corrotinas executam. Hood Chatham, outro autor do post e contribuidor do Pyodide, respondeu:

"Com o WebLoop, corrotinas Python permanecem lazy."

Ele adicionou que a primitiva que um event loop Python precisa é call_later, que mapeia bem para setTimeout, e que usar o loop JavaScript é necessário porque é lá que os eventos de I/O acontecem no runtime. Um segundo loop bloquearia os eventos.

Investimento em upstream: A mesma thread traz o contrapeso à crítica de funding. Simon Willison sugeriu que Cloudflare enviasse dinheiro para Pyodide. Picheta notou que Gyeongjae Choi, outro autor, é desenvolvedor core do Pyodide, e Chatham é um contribuidor do Pyodide que Cloudflare contratou. Dois dos três nomes no anúncio mantêm o projeto no qual o runtime roda.

O caminho à frente

Se essas reações são representativas, o label GA resolve menos do que a engenharia por trás dele. O padrão de empacotamento remove a dependência de um único vendor compilando wheels, e a ponte de syscall deixa drivers existentes funcionarem sem modificações. O que permanece aberto é quem mantém os pieces upstream ao longo do tempo e qual é o custo do runtime na inicialização e na memória.

A Cloudflare publicou padrões de produção num repositório python-workers-examples, e sua documentação para desenvolvedores agora mostra Python junto com JavaScript e TypeScript nos produtos. Sobre performance, a empresa diz apenas que planeja tornar Python Workers mais performante e eficiente em memória.