Cloudflare pone Python Workers en GA y la comunidad pregunta por los cold starts
El runtime sale de la vista previa tras dos años, con bindings a R2, D1 y Workers AI, mientras el mantenedor de urllib3 avisa de que su backend Emscripten sigue fuera de su política de seguridad.
Cloudflare ha declarado disponible de forma general Python Workers, dos años después de la primera vista previa. Python se sienta ya junto a JavaScript y TypeScript en su Developer Platform, con bindings a Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues y Workflows, y soporte para FastAPI, Django y Flask. El anuncio ha traído bastante más debate que nota oficial.
Tres piezas, dos de ellas fuera de casa
El runtime corre sobre Pyodide, así que cualquier paquete con extensión en C, C++ o Rust tiene que compilarse a WebAssembly. Hasta ahora no había forma estándar de hacerlo y era Cloudflare quien compilaba y alojaba esas wheels, lo que limitaba el catálogo disponible. La empresa propuso el PEP 783, que estandariza una plataforma para Python en runtimes de navegador bajo el nombre de PyEmscripten, y se aceptó después de más de un año. También estabilizó la cadena de herramientas de Pyodide y añadió soporte de PyEmscripten a cibuildwheel, para que cada mantenedor genere las suyas.
La segunda pieza es un puente de sockets. Drivers como aiomysql y asyncpg usan el módulo socket de la biblioteca estándar, que hace llamadas al sistema POSIX que dentro de un sandbox WebAssembly son stubs. Cloudflare implementó esas syscalls sobre la API connect de Workers. La traducción ocurre a nivel de syscall, de modo que los drivers no necesitan cambios, y de ahí sale la integración con Hyperdrive.
La tercera son contribuciones aguas arriba en clientes HTTP. requests y httpx pasan ahora por la API fetch de JavaScript en entornos WebAssembly, y eso es lo que permite ejecutar OpenAI, LangChain y MCP dentro de un Worker. Los bindings también se han vuelto más pythónicos: enviar un diccionario a una Queue exigía pasar por to_js con un conversor, y la conversión de tipos ocurre ya en el runtime y el SDK. Los frameworks web llegan por conectores, no por un servidor: workers.asgi y workers.wsgi traducen la petición entrante.
La factura de mantener lo de otros
El punto que más ruido ha generado es la contribución a urllib3. illia-v, mantenedor del proyecto, explicó en Hacker News que aceptaron aportaciones grandes para dar soporte a Pyodide y Emscripten, y después a JSPI, que es lo que hace funcionar a requests. La financiación, dice, fue al colaborador que lo implementó y no a los mantenedores que se quedan con el código: "Hay una diferencia importante entre financiar una contribución a un proyecto aguas arriba y financiar a los mantenedores de ese proyecto". El backend Emscripten sigue marcado como experimental y fuera del alcance de la política de seguridad de urllib3, y señala la CVE-2025-50182, donde los controles de redirección no se comportaron como se esperaba al pasar por fetch. Avisa de que puede haber más diferencias de ese tipo, porque la semántica de red del navegador no es la de su backend habitual.
Los cold starts trajeron números en lugar de quejas. Syrus Akbary, fundador de Wasmer, que vende una plataforma WebAssembly competidora, insistió en lo que ya dijo en el lanzamiento: "Les va a costar bastante lograr menos de 100 ms de arranque con su arquitectura actual". Según un benchmark de su empresa publicado este año, una aplicación Python mínima arrancaba en unos 60 ms en Wasmer Edge frente a unos 900 ms en Cloudflare Workers, y pidió las cifras actuales de p50 y p95 con y sin paquetes nativos. Dominik Picheta, uno de los autores del anuncio, respondió que las instantáneas de memoria ya han mejorado los arranques en frío y que el sharding reduce su frecuencia. Akbary replicó que el post al que remitía daba 1,027 segundos de arranque y preguntó si se había vuelto a medir.
Queda el acoplamiento de versiones: el runtime va atado a la versión de Python y de Pyodide que embebe workerd. Picheta contestó que los flags de compatibilidad permiten elegir entre Python 3.12, 3.13 y 3.14, con la advertencia de que las antiguas traen Pyodide más viejo y menos funciones, JSPI entre ellas. Sobre memoria, un comentarista que no lo había probado apuntó que el parche se come decenas de MB adicionales de la asignación del Worker. En el hilo sobre el bucle de eventos, Hood Chatham, coautor y colaborador de Pyodide, zanjó que con WebLoop las corrutinas de Python siguen siendo perezosas y que usar el bucle de JavaScript es necesario porque ahí ocurren los eventos de E/S.
El sello GA cierra menos de lo que parece. El estándar de empaquetado quita la dependencia de que un proveedor compile las wheels y el puente de syscalls hace que los drivers existentes funcionen sin tocar nada. Lo que sigue abierto es quién mantiene esas piezas aguas arriba con el tiempo, y cuánto cuesta el arranque y la memoria del runtime en producción.
