Python на Cloudflare Workers вышел из беты: FastAPI, Django и драйверы баз

Python на Cloudflare существовал в статусе «посмотрите, что мы умеем» с 2024 года: бета, оговорки, куски кода, где питоновский словарь приходилось вручную конвертировать в JS-объект через to_js(). Теперь компания объявила общую доступность Python Workers и называет язык первоклассным на своей платформе. За формулировкой стоит многолетняя работа, и самое интересное в ней — не сам анонс, а то, какие препятствия пришлось убрать, чтобы обычный питонист мог не думать, где именно исполняется его код.

Фундамент прежний: Pyodide, то есть интерпретатор CPython, собранный в WebAssembly. Wasm в Workers поддерживается с 2018 года, так что запустить Python в песочнице было относительно несложно — сложным оказалось всё остальное.

Границы, которые перестали быть видимыми

Главное изменение для пишущего код — исчезновение ручной конвертации типов на границе между Python и рантаймом. Раньше вызов очереди или базы требовал возни с FFI Pyodide; теперь работает прямой вариант вида self.env.QUEUE.send({"key": "value"}), где словарь остаётся словарём. Это мелочь ровно до того момента, пока не посчитаешь, сколько строк такого клея накапливается в реальном сервисе и сколько ошибок в нём живёт.

Второе — сокеты. В Workers их раньше просто не было в том виде, к которому привыкли питоновские библиотеки. Cloudflare сделали мост системных вызовов, который переводит стандартные операции Python-сокета — открыть соединение, прочитать байты — в соответствующие вызовы рантайма. Следствие этого решения важнее самого решения: заработали драйверы баз данных. aiomysql и asyncpg теперь ходят наружу через Hyperdrive, прокси Cloudflare для SQL, и это делает возможным ровно тот сценарий, ради которого люди и берут Python, — забрать данные из Postgres и что-то с ними сделать.

Третье — фреймворки. FastAPI, Django и Flask запускаются нативно, через пакеты workers.asgi и workers.wsgi. Формально это тонкие коннекторы, переводящие входящий HTTP-запрос в стандарт ASGI или WSGI; практически — возможность взять существующее приложение и не поднимать под него отдельный процесс сервера.

Работа, которую пришлось делать в чужих репозиториях

Самая примечательная часть истории лежит вне Cloudflare. Чтобы Python-на-WebAssembly перестал быть экзотикой, компания провела через процесс стандартизации PEP 783, который закрепляет платформу PyEmscripten. Смысл сугубо практический: теперь сопровождающий любого пакета может собрать wasm-колесо и выложить его так, чтобы оно работало во всех PyEmscripten-совместимых рантаймах, а не только в конкретном продукте конкретного вендора. Параллельно стабилизировали систему сборки Pyodide и добавили поддержку PyEmscripten в cibuildwheel — инструмент, которым колёса собирают в массовом порядке.

Туда же относятся патчи в requests и httpx, научившие их ходить через JS-овый fetch, когда код исполняется в WebAssembly. Это тот тип вклада, который не попадает в заголовки, но определяет, окажется ли платформа пригодной для чужих библиотек или останется песочницей для демонстраций.

Зачем это всё

Список примеров, которые приводит Cloudflare, выдаёт целевую аудиторию: генератор изображений на связке Queues, Workflows, Workers AI и R2; консьюмер потока Bluesky Jetstream через WebSocket, состояние которого держат Durable Objects; серверы Model Context Protocol; RAG-системы на Workers AI и векторной базе Vectorize. Другими словами — та часть работы вокруг моделей, где экосистема Python безальтернативна: OpenAI SDK, LangChain, MCP.

Логика понятна. Спор о языке на бессерверных платформах последние годы выигрывал JavaScript не потому, что он лучше подходит для обработки данных, а потому, что рантаймы были написаны под него. Как только вокруг моделей сложилась библиотечная экосистема на Python, издержки этого перекоса стали слишком заметными: люди писали прототип на Python, а в продакшен переписывали на TypeScript.

Чего в анонсе нет

Стоит честно сказать и об умолчаниях. В объявлении не приводятся ни цифры холодного старта, ни потребление памяти, ни бенчмарки — при том, что интерпретатор в WebAssembly традиционно именно здесь и вызывает вопросы. Нет и деталей по тарификации и лимитам для Python-воркеров. Для платформы, которая продаёт себя близостью исполнения к пользователю и мгновенным стартом, это заметная лакуна: человеку, выбирающему между питоновским воркером и контейнером, сравнивать пока нечего, кроме удобства.

Тем не менее направление считывается однозначно. Cloudflare не стали делать «питоноподобный» диалект поверх своего рантайма, а потратили годы на то, чтобы обычный Python с обычными пакетами и обычными фреймворками работал внутри песочницы, где физически нет ни процессов, ни файловой системы в привычном виде. Если PEP 783 действительно приживётся у сопровождающих пакетов, выигрыш достанется не одной платформе: колёса под WebAssembly станут такой же рутиной, как колёса под Linux, и Python начнёт появляться в тех местах, куда его раньше не звали.

Анонс с примерами кода — в блоге Cloudflare.