Cloudflare Python Workers 正式发布 GA

崔庆宰：/author/gyeongjae-choi/ , 多米尼克·皮切塔：/author/dominik/ , 以及胡德·查瑟姆：/author/hood/

两年前，我们推出了 Python Workers，为在 Cloudflare Workers 运行时运行 Python 应用程序提供了一种方式：https://blog.cloudflare.com/python-workers/。我们的目标是让用 Python 编写 Workers 和用 TypeScript 编写一样简单，并让 Python 包和框架生态系统“直接可用”。

今天，Python Workers 现已普遍可用 (GA)。

GA 意味着什么？这意味着 Python 现在是 Cloudflare 开发者平台上的一级、完全支持的语言。你可以带来你已经熟悉的 Python 代码、库和设计模式，并将它们无缝连接到 Workers AI、R2、D1、Hyperdrive、Durable Objects、Queues、Workflows 以及 Cloudflare 平台的其他部分。你还可以在 Python Workers 内运行流行的 Python 框架，如 FastAPI、Django 和 Flask。你甚至可以使用 Dynamic Workers：https://blog.cloudflare.com/dynamic-workers/ 在另一个 Worker 内创建 Python Worker。

将 Python 引入 Cloudflare Workers 是一个自然的选择。因为 Workers 自 2018 年起就支持 WebAssembly：https://blog.cloudflare.com/webassembly-on-cloudflare-workers/，它为我们运行 Wasm 编译的 Python 解释器提供了完美的环境。通过使用 Pyodide：https://pyodide.org/en/stable/，我们能够快速支持不同类型的 Python 应用程序在 Cloudflare Workers 中运行。

我们的目标是创建第一个可无限扩展的 Python 应用平台，同时让开发 Python 应用变得像在其他地方一样简单和高效。

我们今天要强调的功能是多年努力的结果。许多开发者已经在 Python Workers 中构建应用程序；今天，我们将这些功能变为面向所有人的生产就绪版本。

Python Workers 现在原生支持 Cloudflare 开发者平台绑定。以前，在 Python Workers 中使用这些 Cloudflare 绑定需要在 RPC 边界显式地将 Python 对象转换为 TypeScript 对象。例如，将一个 Python 字典发送到 Cloudflare Queue 中，需要以下粘合代码才能工作：

这要求 Python 开发者在编写 Python Workers 时同时考虑 JavaScript 环境和代码，这对人类和 AI 代理来说都是一个常见的错误来源。为了解决这个问题，我们在 Workers 运行时和 Python SDK 内封装了整个类型转换过程：https://blog.cloudflare.com/python-workers-rpc/。这使你能够以 Python 风格使用所有 Cloudflare 绑定，而无需编写一行 JavaScript 代码，从而使以下操作能够直接工作：

你现在可以运行你喜欢的 Python 框架，例如 FastAPI、Django 或 Flask，在 Python Workers 中构建 API 服务器。我们实现了一个内置连接器，你可以用它轻松地将你的 Web 应用连接到 Python Workers。

假设你有一个简单的 FastAPI 网络应用程序：

在本地环境中，你会使用 uvicorn 这样的 Web 服务器运行该应用。

在 Python Workers 中，你可以使用我们提供的 workers.asgi 包运行相同的应用，只需在代码中添加这段代码：

同样，你可以使用 workers.wsgi 包运行像 Django 这样的同步 Web 应用。

Python 有一个标准规范来定义 Web 应用如何与 Web 服务器通信，这被称为 Web 服务器网关接口（WSGI），或者其现代异步版本 ASGI。该标准允许开发者构建完全与服务器无关的应用。在传统部署中，Uvicorn 或 Gunicorn 这样的 Web 服务器负责处理多个并发客户端连接和线程以扩展流量，而像 FastAPI 这样的 Web 框架则可以专注于应用逻辑。

在 Cloudflare Workers 中，Workers 平台本身充当 Web 服务器。由于我们的全球网络已经无缝处理负载均衡和无限扩展，我们无需在 Python Workers 内部运行服务器来重新发明轮子。

相反，我们的 workers.asgi 和 workers.wsgi 连接器充当了薄而优化的桥梁。它们将收到的原生 JavaScript 请求转换为 Python 应用期望的标准 WSGI/ASGI 结构，并无缝地将响应输出，开销最小。通过这样做，Python 开发者可以两全其美：你可以用喜欢的 Web 框架编写和组织代码，同时让 Cloudflare Workers 平台即时将你的 API 扩展到全球，而无需配置服务器。

这些连接器不仅可以用于FastAPI、Django或Flask，还可以用于任何使用WSGI：https://peps.python.org/pep-3333/ 或ASGI：https://asgi.readthedocs.io/en/latest/ 接口的Python网页框架。

你可以在 Python Workers 文档中找到更多关于使用每个 Web 框架的信息：https://developers.cloudflare.com/workers/languages/python/packages/。

如果你正在使用关系数据库如PostgreSQL或MySQL构建Python应用，现在你可以将Hyperdrive：https://developers.cloudflare.com/hyperdrive/ 集成到Python Workers中。

此前，Python Workers 不支持 TCP 套接字，导致数据库驱动程序不可用。要理解为什么这是阻碍，你需要看看 WebAssembly 的运行方式。像 aiomysql 或 asyncpg 这样的 Python 数据库驱动程序依赖标准库的套接字模块来建立连接。在标准环境中，该模块向底层操作系统发起 POSIX 系统调用。在 WebAssembly 沙箱中，这些 POSIX 网络系统调用通常是总是失败的存根。任何尝试打开标准套接字都会立即失败。为了解决这个问题，我们使用 Workers connect：https://developers.cloudflare.com/workers/runtime-apis/tcp-sockets/ API 实现了套接字系统调用。

当数据库驱动程序尝试打开 TCP 连接时，会经过我们自定义的套接字系统调用实现。它将标准的 Python 套接字操作，如打开连接和读取字节，转换成 Workers 运行时使用的相应 JavaScript 调用。由于这种转换发生在系统调用层面，你的数据库驱动程序根本不需要知道底层实现。

这个套接字桥使我们的 Hyperdrive 集成成为可能。要在 Python Workers 中使用 Hyperdrive，首先将您的数据库与 Hyperdrive 连接，并在 Wrangler 配置中设置绑定：

然后，使用您熟悉的数据库驱动连接到 Hyperdrive：

您可以参考 Hyperdrive Python Workers 文档：https://developers.cloudflare.com/hyperdrive/examples/python-workers/，了解如何在 Python Workers 中使用 Hyperdrive，以及目前支持哪些软件包。

因为 Python Workers 在 WebAssembly 沙箱中运行，任何带有原生 C/C++/Rust 扩展的包都必须交叉编译为 WebAssembly 才能在 Python Workers 中运行。然而，以前没有标准方法将任何 Python 包交叉编译为 WebAssembly。这意味着我们的团队必须手动编译和托管自定义 WebAssembly 包。这大大限制了您实际上可以在 Python Workers 中使用的软件包数量。

我们希望解决这个问题，让用户能够使用更多种类的软件包。然而，我们不希望仅仅构建只能在 Python Workers 中使用的软件包，因为这样对社区没有益处。由于 Python Workers 构建在 Pyodide 之上，我们希望生态系统以一种有利于 Pyodide 及整个 Python-on-WebAssembly 社区的方式发展。

为此，我们提出了 PEP 783：https://peps.python.org/pep-0783/，该提案为在浏览器运行时中运行 Python 标准化了一个平台，称为 PyEmscripten。经过一年多的讨论和完善，该提案被接受，使软件包维护者能够为 PyEmscripten 平台构建和发布软件包，并使其在所有实现 PyEmscripten 的环境中可用。

我们还稳定了现有的 Pyodide 构建工具链，并将其发展成所有软件包维护者都可以访问的形式，使开发者能够轻松为 PyEmscripten 平台构建软件包。此外，我们还为 cibuildwheel 添加了 PyEmscripten 平台支持：https://cibuildwheel.pypa.io/en/stable/，以便其他人更容易采用对 PyEmscripten 平台的支持。

Gyeongjae Choi ：/author/gyeongjae-choi/ , Dominik Picheta ：/author/dominik/ , and Hood Chatham ：/author/hood/

We introduced Python Workers two years ago, providing a way to run Python applications ：https://blog.cloudflare.com/python-workers/ in the Cloudflare Workers runtime. Our goal was to make it as simple to write Workers in Python as it is in TypeScript, and to make the ecosystem of Python packages and frameworks “just work”.

Today, Python Workers are now generally available (GA).

What does GA mean? It means Python is now a first-class, fully supported language on the Cloudflare Developer Platform. You can bring the Python code, libraries, and design patterns you already know and connect them seamlessly to Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues, Workflows, and the rest of the Cloudflare platform. You can also run popular Python frameworks like FastAPI, Django, and Flask inside Python Workers. You can even create a Python Worker inside another Worker using Dynamic Workers ：https://blog.cloudflare.com/dynamic-workers/.

Bringing Python to Cloudflare Workers was a natural choice. Because Workers has supported WebAssembly since 2018 ：https://blog.cloudflare.com/webassembly-on-cloudflare-workers/, it gave us the perfect environment to run a Wasm-compiled Python interpreter. By using Pyodide ：https://pyodide.org/en/stable/, we were able to quickly support a wide range of Python applications in Cloudflare Workers.

Our goal was to create the first platform for infinitely scalable Python apps, while making it as easy and performant as developing Python apps anywhere else.

The features we are highlighting today are the result of this multi-year effort. Many developers are already building applications within Python Workers; today, we are making these capabilities production-ready for everyone.

Python Workers now natively support Cloudflare Developer Platform bindings. Previously, using these Cloudflare bindings in Python Workers required converting Python objects into TypeScript objects explicitly at the RPC boundary. For example, sending a Python dictionary into a Cloudflare Queue required the following glue code to work:

This required Python developers to keep the JavaScript environment and code in mind while writing Python Workers, and it was a common source of error for both humans and AI agents. To address this, we have encapsulated the entire type conversion process ：https://blog.cloudflare.com/python-workers-rpc/ within the Workers runtime and the Python SDK. This allows you to utilize all Cloudflare bindings in a Pythonic way without writing a single line of JavaScript code, making the following just work:

You can now run your favorite Python framework, such as FastAPI, Django, or Flask, to build an API server in Python Workers. We implemented a built-in connector that you can use to easily connect your web application to Python Workers.

Let’s say you have a simple FastAPI web application:

In native environments, you would use a web server such as uvicorn to run this application.

In Python Workers, you can run the same application using the workers.asgi package we provide, just by adding this snippet to your code:

Similarly, you can use workers.wsgi package to run synchronous web applications such as Django.

Python has a standard contract for how web applications should communicate with web servers, known as the Web Server Gateway Interface (WSGI), or its modern asynchronous counterpart, ASGI. This standard allows developers to build applications that are completely server-agnostic. In a traditional deployment, web servers like Uvicorn or Gunicorn are responsible for handling multiple concurrent client connections and threads to scale traffic, while web frameworks like FastAPI can focus purely on the application logic.

In Cloudflare Workers, the Workers platform itself serves as the web server. Since our global network already seamlessly handles load balancing and infinite scaling, we don't need to reinvent the wheel by running a server inside Python Workers.

Instead, our workers.asgi and workers.wsgi connectors act as a thin, optimized bridge. They translate the incoming native JavaScript request into the standard WSGI/ASGI structures that Python applications expect, and seamlessly pipe the response back out with minimal overhead. By doing this, Python developers get the best of both worlds: you can write and organize code using your favorite web frameworks, while letting the Cloudflare Workers platform instantly scale your API across the globe, without ever configuring a server.

These connectors can be used not only with FastAPI, Django, or Flask, but with any Python web framework that uses the WSGI ：https://peps.python.org/pep-3333/ or ASGI ：https://asgi.readthedocs.io/en/latest/ interface.

You can find more information about using each web framework in the Python Workers documentation ：https://developers.cloudflare.com/workers/languages/python/packages/.

If you are building a Python application using relational databases such as PostgreSQL or MySQL, you can now integrate Hyperdrive ：https://developers.cloudflare.com/hyperdrive/ into Python Workers.

Previously, Python Workers didn’t support TCP sockets, making database drivers unavailable. To understand why this was a blocker, you need to look at how WebAssembly operates. Python database drivers like aiomysql or asyncpg rely on the standard library's socket module to establish connections. In a standard environment, this module makes POSIX system calls to the underlying operating system. Inside a WebAssembly sandbox, those POSIX networking syscalls are normally stubs that always fail. Any attempt to open a standard socket would immediately fail. To solve this problem, we implemented socket system calls using the Workers connect ：https://developers.cloudflare.com/workers/runtime-apis/tcp-sockets/ API.

When a database driver attempts to open a TCP connection, it goes through our custom socket syscall implementation. It translates standard Python socket operations like opening a connection and reading bytes into the corresponding JavaScript calls used by the Workers runtime. Because this translation happens at the system call level, your database drivers don't have to know about the underlying implementation at all.

This socket bridge is what makes our Hyperdrive integration possible. To use Hyperdrive in Python Workers, first connect your database with Hyperdrive and set up the binding in the Wrangler config:

Then, connect to Hyperdrive using the database drivers you are familiar with:

You can refer to the Hyperdrive Python Workers documentation ：https://developers.cloudflare.com/hyperdrive/examples/python-workers/ to find out how you can use Hyperdrive in Python Workers, and which packages are currently supported.

Because Python Workers run inside a WebAssembly sandbox, any packages with native C/C++/Rust extensions must be cross-compiled to WebAssembly to run in Python Workers. However, previously, there was no standard way to cross-compile any Python packages to WebAssembly. That meant our team had to manually compile and host custom WebAssembly packages. This greatly limited the number of packages you could actually use in Python Workers.

We wanted to fix this and allow users to use a wider variety of packages. However, we didn’t want to merely build packages usable only in Python Workers, which wouldn’t benefit the community. Since Python Workers are built on top of Pyodide, we wanted the ecosystem to evolve in a way that benefits Pyodide and the entire Python-on-WebAssembly community.

To this end, we proposed PEP 783 ：https://peps.python.org/pep-0783/, which standardizes a platform for running Python in the browser runtimes called PyEmscripten. After over a year of discussion and refinement, this proposal was accepted, enabling package maintainers to build and publish packages for the PyEmscripten platform and make them available across all environments that implement PyEmscripten.

We also stabilized the existing Pyodide build toolchain and evolved it into a form that is accessible to all package maintainers, enabling developers to easily build packages for the PyEmscripten platform. Furthermore, we added PyEmscripten platform support to cibuildwheel ：https://cibuildwheel.pypa.io/en/stable/, to make it easier for others to adopt support for the PyEmscripten platform.