Cloudflare leva Python Workers à disponibilidade geral, mas cold start ainda divide a comunidade

A Cloudflare anunciou a disponibilidade geral (GA) do runtime 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) → para Workers, dois anos depois do primeiro preview, segundo reportagem da InfoQ. Python passa a sentar ao lado de JavaScript e TypeScript no Developer Platform da empresa, com bindings para Workers AI↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →, R2, D1, Hyperdrive, Durable Objects, Queues e Workflows, além de suporte a FastAPI, Django e Flask.

Para quem já roda funções serverless em Python em outra nuvem, ou cogita migrar uma API pequena para a borda da Cloudflare, o anúncio importa menos pelo rótulo GA e mais pelo que ficou por baixo dele. Três peças de engenharia tornaram o lançamento possível, e duas delas não vieram da própria Cloudflare.

O padrão de empacotamento que faltava

Workers em Python rodam sobre o Pyodide, o que significa que qualquer pacote com extensão em C, C++ ou Rust precisa ser cross-compilado para WebAssembly. Até a GA não existia um jeito padronizado de fazer isso, e a Cloudflare compilava e hospedava esses pacotes por conta própria, o que limitava quantos ficavam disponíveis.

A empresa propôs a PEP 783, que padroniza uma plataforma para Python em runtimes de navegador chamada PyEmscripten, aceita depois de mais de um ano de discussão. A Cloudflare também estabilizou a toolchain de build do Pyodide e adicionou suporte a PyEmscripten no cibuildwheel, permitindo que mantenedores de pacotes compilem suas próprias wheels sem depender da Cloudflare como intermediária.

Uma ponte de sockets para drivers existentes

Drivers como aiomysql e asyncpg usam o módulo socket da biblioteca padrão, que faz chamadas de sistema POSIX. Dentro de um sandbox WebAssembly, essas chamadas são apenas stubs. A Cloudflare implementou essas syscalls sobre a API connect do Workers, com a tradução acontecendo no nível da chamada de sistema.

Na prática, isso significa que os drivers não precisaram de nenhuma alteração para funcionar, e é essa ponte que faz a integração com Hyperdrive funcionar de fato.

HTTP client rodando via fetch do navegador

A terceira peça envolveu contribuições da própria Cloudflare a bibliotecas de terceiros. Hoje, requests e httpx roteiam requisições através da API fetch do JavaScript quando rodam em ambiente WebAssembly, o que é o que permite que OpenAI, LangChain e MCP funcionem dentro de um Worker.

Os bindings também ficaram mais pythônicos: enviar um dicionário para uma Queue antes exigia conversão manual via to_js com um conversor de dict; agora a conversão de tipos acontece dentro do runtime e do SDK. Frameworks web chegam por conectores em vez de um servidor próprio: workers.asgi e workers.wsgi traduzem requisições JavaScript recebidas nas estruturas que aplicações WSGI e ASGI esperam.

O atrito com quem mantém o urllib3

A terceira peça, a que envolveu httpx e requests, foi a que gerou a reação mais dura. Escrevendo no Hacker News como mantenedor do urllib3, o usuário illia-v explicou que o projeto recebeu grandes contribuições adicionando suporte a Pyodide e Emscripten, e depois suporte a JSPI, que é o que viabilizou o funcionamento do requests.

Existe uma diferença significativa entre financiar uma contribuição a um projeto upstream e financiar os mantenedores upstream.

There is a meaningful difference between funding a contribution to an upstream project and funding the upstream maintainers.illia-v, mantenedor do urllib3

Essa diferença aparece na postura do próprio projeto: o backend Emscripten segue experimental no urllib3 e está explicitamente fora do escopo da política de segurança. Ele cita a CVE-2025-50182, em que os controles de redirecionamento do urllib3 não se comportaram como esperado depois que as requisições passaram a ser roteadas via fetch, e alerta que pode haver mais diferenças desse tipo, já que a semântica de rede do navegador difere do backend usual do urllib3.

Cold start: números que não batem

A discussão sobre tempo de partida veio com números, não só reclamações. Syrus Akbary, fundador da Wasmer, que vende uma plataforma WebAssembly concorrente, retomou uma preocupação levantada já no lançamento em preview:

Vai ser bem difícil para eles atingirem um tempo de inicialização abaixo de 100ms com a arquitetura atual.

It will be quite hard for them to achieve <100ms startup time with their current architecture.Syrus Akbary, fundador da Wasmer

Ele disse que uma aplicação Python mínima iniciou em cerca de 60ms no Wasmer Edge contra cerca de 900ms no Cloudflare Workers, em um benchmark publicado pela própria empresa dele ainda neste ano, e pediu números atuais de p50 e p95, com e sem pacotes nativos.

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

Nossa implementação de snapshot de memória já melhorou significativamente os cold starts.

Our memory snapshot implementation has improved the cold starts significantly already.Dominik Picheta, Cloudflare

Ele acrescentou que o sharding reduz a frequência com que cold starts acontecem, e apontou para um post anterior com números. Akbary retrucou que esse post relatava um tempo de inicialização de cerca de 1,027 segundo, e perguntou se a medição tinha sido refeita desde então.

Versão acoplada e memória extra

O segundo ponto de atrito de Akbary foi o acoplamento de versão: Python Workers ficam presos à versão do Python e do Pyodide que o workerd embute. Picheta respondeu que flags de compatibilidade selecionam entre Python 3.12, 3.13 e 3.14, mas reconheceu que versões mais antigas trazem releases mais antigos do Pyodide, com menos recursos, entre eles o JSPI. Akbary leu essa resposta como confirmação do problema, já que a flag também move o workerd junto.

Memória levantou uma preocupação separada de outro comentarista, dangoodmanUT, que disse não ter testado a afirmação:

Isso provavelmente consome dezenas de MB a mais na alocação de memória do worker.

This likely eats in 10's of MBs more into the worker memory allocation.dangoodmanUT, comentarista no Hacker News

O debate técnico sobre o loop de eventos

Uma das trocas fechou um ponto técnico em vez de comercial. Akbary argumentou que fazer o Python usar o loop de eventos do JavaScript cria incompatibilidade, já que os dois diferem em quando as corrotinas executam. Hood Chatham, outro autor do post e contribuidor do Pyodide, respondeu:

Com o WebLoop, as corrotinas Python permanecem preguiçosas.

With the WebLoop, Python coroutines stay lazy.Hood Chatham, contribuidor do Pyodide

Ele acrescentou que a primitiva de que um loop de eventos Python precisa é call_later, que mapeia diretamente para setTimeout(), e que usar o loop do JavaScript é necessário porque é ali que os eventos de I/O acontecem no runtime. Um segundo loop bloquearia esses eventos.

A mesma discussão carrega o contraponto à própria crítica sobre financiamento. Simon Willison sugeriu que a Cloudflare mandasse dinheiro para o Pyodide. Picheta apontou que Gyeongjae Choi, outro autor do post, é core developer do Pyodide, e que Chatham é um contribuidor do Pyodide contratado pela Cloudflare: dois dos três nomes no anúncio mantêm o próprio projeto sobre o qual o runtime roda.

O que muda para quem programa em Python no Brasil

Para equipes brasileiras que já usam Cloudflare Workers em JavaScript e cogitam levar uma API Python para a borda, a GA reduz o risco de depender de um pacote WASM compilado só pela Cloudflare: com a PEP 783 e o cibuildwheel atualizados, é possível compilar a própria wheel de uma dependência C/Rust que ainda não esteja disponível.

A ponte de sockets também importa na prática: bancos de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → acessados via aiomysql ou asyncpg funcionam sem reescrever o driver, o que facilita usar Hyperdrive com um banco Postgres ou MySQL já existente. Já quem depende de requests ou httpx para chamar APIs de modelos de IA ganha compatibilidade de fábrica com OpenAI, LangChain e MCP dentro do Worker.

O que ainda fica em aberto, segundo a reportagem da InfoQ, é dividido em duas frentes:

• Cold start e memória: a Cloudflare afirma apenas que planeja tornar o runtime Python mais performático e eficiente em memória, sem compromisso de número, enquanto a concorrência publica benchmarks próprios com resultados bem distantes.
• Manutenção upstream: bibliotecas como urllib3 seguem tratando o caminho Emscripten como experimental e fora da política de segurança, o que é relevante para quem for colocar esse runtime em produção com dados sensíveis.

A Cloudflare publicou padrões de produção no repositório python-workers-examples, e a documentação para desenvolvedores já mostra Python ao lado de JavaScript e TypeScript em todos os produtos da plataforma.

Fonte: InfoQ