Python Workers: flags, entrypoint, and package installs

# Python Workers: the setup that actually runs

Python Workers are first-class: FastAPI, Langchain, Pydantic and more install as packages, and a foreign function interface lets Python call JavaScript objects directly, including all Workers Runtime APIs. But the setup has three non-obvious requirements.

## 1. The compatibility flag is mandatory

Add the `python_workers` compatibility flag to your Worker. Without it, the Python entrypoint does not run. This is the most common silent failure: everything looks configured, nothing executes.

## 2. The entrypoint shape

A Python Worker is a class extending `WorkerEntrypoint` from the `workers` SDK module, with an async `fetch` method:

```python
from workers import WorkerEntrypoint, Response

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        return Response("Hello World!")
```

The class must be named `Default`. The `fetch` handler is where incoming requests land, same as JavaScript Workers.

## 3. Use pywrangler, not plain wrangler, for the Python flow

Install with `uv` and Node present, then:

```bash
uvx --from workers-py pywrangler init
```

pywrangler handles running locally, installing packages, and deploying. Bindings (KV, D1, R2, Durable Objects, Queues, Workers AI, Vectorize) are configured the same way as JS Workers and accessed via `self.env` in Python.

## Checklist

- `python_workers` flag present before you debug anything else.
- Package installs go through the Python packages flow documented on the Python Workers pages; do not assume every PyPI package works, check the supported-packages list.
- Access env, secrets, and bindings through `self.env`, same binding names as your Wrangler config.