Starlette: Trio support.

[tomchristie]

Via https://gitter.im/python-trio/general?at=5e2fe9b940da694c5edc8d70

It'd be nice to have Starlette support both Trio and Asyncio.

Currently it's an asyncio-only framework, but there's actually not many places where we're tied to asyncio, with the exception of a bunch of "if this callable is a plain function then call into with with run_in_threadpool, otherwise await it.".

I think the other places are:

• The WSGI middleware (optional). Currently has an asyncio-based implementation.
• The BaseHTTPMiddleware class (optional), that provides a request/response middleware interface to develop against, rather than directly writing against ASGI. Again, currently has an asyncio-based implemention.
• One weird part of the request model, .is_disconnected - that I think is structured as an anti-pattern and probably needs rethinking.
• The graphene-based GraphQL async executor, which probably ought to come out of the core package anyways.
• The existing TestClient, which we oughta replace with httpx now anyways, which does have trio+asyncio.

Short: Tweaking our run_in_threadpool function to use sniffio and then either call trio's threadpooling or asyncio's threadpooling would be sufficient as a starting point to start using Starlette with Trio.

[gdhameeja]

I'm taking this up.

[jtrakk]

@gdhameeja Can you share a link to your repo so we can follow along?

[tammoippen]

Also, FileResponse uses aiofiles, which is asyncio based. Here the trio i/o could be used?

Edit: And StaticFiles.

[parity3]

I figured these possible alternatives / POC / intermediate steps are worth mentioning here.

• trio-asyncio
• anyio

[pquentin]

For what it's worth, here's an example of Uvicorn + Starlette + FastAPI running with trio-asyncio: https://github.com/python-trio/trio-asyncio/issues/84