Os Python Workers generally available, blog oficial da Cloud... (blog.cloudflare.com)">Python Workers da Cloudflare chegaram à disponibilidade geral (GA) em, dois anos após o primeiro preview, colocando Python ao lado de JavaScript e TypeScript na PEP 783, plataforma PyEmscripten para Python em browsers (peps.python.org) de desenvolvedores da empresa. O runtime ganha bindings para Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues e Workflows, além de suporte aos frameworks FastAPI, Django e Flask.
A novidade desembarca em um debate que já esquentou nos fóruns técnicos: cold starts próximos de 1 segundo, versões acopladas do interpretador e uma discussão pública sobre quem paga a conta da manutenção das bibliotecas upstream que tornam tudo isso possível.
Principais pontos
- Duas das três bases de engenharia do GA foram contribuídas fora da Cloudflare, incluindo o padrão de empacotamento PEP 783.
- Drivers como aiomysql e asyncpg rodam sem alteração graças a uma ponte de syscalls sobre a API connect.
- Mantenedor do urllib3 questiona o modelo de financiamento e aponta o CVE-2025-50182 como exemplo de divergência de comportamento.
- Cold start medido em torno de 1 segundo, contra cerca de 60 ms no Wasmer Edge, segundo benchmark concorrente.
O que a Cloudflare entregou no GA dos Python workers
Python Workers é a execução de código Python no edge da Cloudflare, compilada para WebAssembly via Pyodide. Na prática, isso leva uma das linguagens mais populares do mundo para a mesma infraestrutura serverless que já roda JavaScript e TypeScript.
Os bindings cobrem praticamente todo o portfólio da plataforma: Workers AI, armazenamento de objetos R2, banco D1, Hyperdrive para aceleração de bancos existentes, Durable Objects, Queues e Workflows. A conversão de tipos passou a acontecer dentro do próprio runtime e do SDK, o que elimina o antigo malabarismo com to_js e conversores de dicionário ao enviar dados para uma fila.
Um Worker mínimo em Python fica assim:
# publicidade
from workers import Response
def on_fetch(request):
return Response.json({"hello": "world"})Mas por que frameworks conhecidos como FastAPI, Django e Flask funcionam sem um servidor web tradicional dentro do Worker? A resposta da Cloudflare é que a plataforma já é o servidor: conectores como workers.asgi e workers.wsgi traduzem as requisições JavaScript recebidas para as estruturas que aplicações WSGI e ASGI esperam.
As três peças de engenharia por trás do lançamento
O GA só foi possível por três frentes de engenharia, e a Cloudflare reconhece que duas delas aconteceram fora das suas paredes.
Pep 783 e cibuildwheel padronizam pacotes com extensão nativa
Como o runtime roda sobre WebAssembly, qualquer pacote Python com extensão em C, C++ ou Rust precisa ser cross-compilado, e não existia um padrão para isso. A Cloudflare compilava e hospedava esses pacotes por conta própria, o que limitava o catálogo disponível. A empresa propôs a PEP 783, que padroniza a plataforma PyEmscripten para runtimes Python no navegador, e ela foi aceita após mais de um ano de discussão.
Em paralelo, a toolchain de build do Pyodide foi estabilizada e o suporte a PyEmscripten chegou ao cibuildwheel, ferramenta amplamente usada por mantenedores para gerar wheels. Com isso, os próprios projetos passam a poder publicar seus binários WebAssembly sem depender de um fornecedor terceiro para compilar.
Ponte de syscalls e contribuições nas bibliotecas HTTP
A segunda peça conecta drivers de banco de dados ao sandbox. Bibliotecas como aiomysql e asyncpg usam o módulo socket da biblioteca padrão, que faz chamadas POSIX viradas para stubs dentro do WebAssembly. A Cloudflare implementou essas syscalls sobre a API connect dos Workers, de forma que a tradução acontece no nível da syscall e os drivers não precisam de nenhuma modificação. É isso que faz a integração com Hyperdrive funcionar.
A terceira frente foi na camada HTTP. Bibliotecas como requests e httpx agora roteiam pelo fetch do JavaScript em ambientes WebAssembly, o que permite rodar SDKs de OpenAI, LangChain e MCP dentro de um Worker. E foi exatamente essa peça que atraiu a reação mais dura da comunidade.
Por que mantenedores de bibliotecas questionam o modelo
Escrevendo no Hacker News como mantenedor do urllib3, o desenvolvedor illia-v explicou que o projeto integrou contribuições grandes para suporte a Pyodide, Emscripten e, depois, JSPI, o que viabilizou o requests nesse cenário. O problema, segundo ele, é que o financiamento foi para o contribuidor que implementou, não para os mantenedores que ficaram responsáveis pelo código.
Existe uma diferença significativa entre financiar uma contribuição a um projeto upstream e financiar os mantenedores do próprio upstream, escreveu illia-v.
A postura do urllib3 reflete essa tensão: o backend Emscripten continua experimental no projeto e está explicitamente fora do escopo da política de segurança. O mantenedor aponta o CVE-2025-50182, em que os controles de redirecionamento do urllib3 não se comportaram como esperado quando as requisições passaram a ir pelo fetch, e alerta para outras divergências possíveis, já que a semântica de rede do navegador difere do backend tradicional.
Atenção: se sua aplicação depende de comportamentos específicos de redirect ou de controle fino de conexão via urllib3, vale testar no ambiente WebAssembly antes de levar a produção. O backend Emscripten não é coberto pela política de segurança do projeto.
Mas existe contrapeso dentro da própria thread de discussão? Simon Willison sugeriu que a Cloudflare direcionasse recursos ao Pyodide, e a resposta veio com nomes: Gyeongjae Choi, um dos autores do anúncio, é core developer do Pyodide, e Hood Chatham, outro autor, é um contribuidor do projeto que a Cloudflare contratou. Ou seja, dois dos três autores do anúncio mantêm o projeto sobre o qual o runtime roda.
Cold starts, memória e versionamento: os números na mesa
Syrus Akbary, fundador da Wasmer, empresa que vende uma plataforma concorrente baseada em WebAssembly, revisou críticas feitas no lançamento original.
Ele afirma que será difícil para a Cloudflare atingir cold start abaixo de 100 ms com a arquitetura atual, cita um benchmark da sua própria empresa com cerca de 60 ms no Wasmer Edge contra 900 ms nos Workers para uma aplicação Python mínima, e pediu números atuais de p50 e p95 com e sem pacotes nativos.
| Plataforma | Cold start (app mínima) | Origem do dado |
|---|---|---|
| Wasmer Edge | ~60 ms | Benchmark publicado pela Wasmer (concorrente) |
| Cloudflare Python Workers | ~900 ms | Mesmo benchmark da Wasmer |
| Cloudflare Python Workers | ~1.027 s | Post anterior da própria Cloudflare, citado por Akbary |
Arraste para o lado para ver toda a tabela.
Dominik Picheta, um dos autores do anúncio, respondeu do lado da Cloudflare: a implementação de snapshots de memória já melhorou significativamente os cold starts, e o sharding reduz a frequência com que eles ocorrem, apontando um post anterior com números. A réplica de Akbary notou que esse post reportava startup de cerca de 1,027 segundo e perguntou se a medição foi refeita desde então.
Info: as compatibility flags dos Workers permitem escolher entre Python 3.12, 3.13 e 3.14, mas versões antigas trazem releases antigos do Pyodide, com menos recursos como o JSPI.
O versionamento acoplado foi a outra objeção de Akbary: o Worker fica preso à versão de Python e Pyodide embutida no workerd. Picheta respondeu que as flags selecionam a versão, mas Akbary leu isso como confirmação do problema, já que a flag também altera o workerd inteiro.
Já o comentador dangoodmanUT levantou preocupação de memória, sem ter testado: a carga provavelmente consome dezenas de MB a mais do limite de alocação do Worker.
Houve ainda um ponto técnico resolvido na conversa. Akbary argumentou que adaptar o event loop do Python ao loop do JavaScript cria incompatibilidade na execução de corrotinas.
Hood Chatham respondeu que, com o WebLoop, as corrotinas Python seguem lazy, e que a primitiva necessária é o call_later, que mapeia diretamente para o setTimeout.
Usar o loop do JavaScript é necessário porque é lá que os eventos de I/O acontecem no runtime, e um segundo loop bloquearia esses eventos.
Dica: quer ver padrões de produção prontos? A Cloudflare publicou o repositório python-workers-examples no GitHub, e a documentação da plataforma já mostra Python ao lado de JavaScript e TypeScript nos produtos.
O que isso significa para quem desenvolve no brasil
Na avaliação do Mercado de TI, o rótulo de GA resolve menos do que a engenharia por baixo dele. O padrão de empacotamento elimina a dependência de um único fornecedor compilando wheels, e a ponte de syscalls faz drivers existentes funcionarem sem alteração. Ficam em aberto duas perguntas: quem sustenta os componentes upstream no longo prazo, e quanto o runtime custa em cold start e memória.
Para times brasileiros que já concentram sistemas no edge, o custo de latência de cold start pesa diferente: um Worker sem pacotes nativos rodando em regiões atendidas pela malha da Cloudflare, que recentemente redesenhou o cache DNS do 1.1.1.1 em Rust, tende a ter sharding reduzindo as inicializações a frio. Já APIs em FastAPI com dependências pesadas sentirão os dezenas de megabytes extras de memória apontados na discussão.
O movimento também se encaixa em uma estratégia maior da empresa em torno de IA no edge, na linha do protocolo x402, que trouxe micropagamentos para o edge junto com a AWS, e de novos motores como o Kitesurf, navegador leve para agentes de IA nos Workers. Ter Python de primeira classe é o elo que faltava para o ecossistema de IA, majoritariamente Python, chegar a essa infraestrutura.
O rótulo de GA está posto; os tempos de inicialização e a manutenção do urllib3 e do Pyodide serão o termômetro. A Cloudflare diz apenas que planeja tornar os Python Workers mais performáticos e eficientes em memória. Acompanhar os próximos números de p50 e p95, quando publicados, é o que separa a promessa do veredito.
Fonte: Infoq
