Sebastián Ramírez

@skewty I think that would belong to the "application development" side. It would probably involve some kind of message passing system/DB. E.g. a Redis instance and connections between different processes...

Thanks for the feedback @jhominal. On the FastAPI side, I already solved it and merged the PR there. I'm gonna wait to hear more feedback here, hopefully @tomchristie will have...

@Kludex found the previous conversation where it seems this was decided: https://gitter.im/encode/community?at=61d82b1a82a4667b2563bfc3 I'm gonna wait and see if @tomchristie has any other opinion. Or if it should be an exception...

Thanks for the feedback everyone! Yep, I get it and it makes sense. I already solved the problem on the FastAPI side, so having it here in Starlette or not...

This is intentional behavior on the Starlette side as discussed in the PR: https://github.com/encode/starlette/pull/1765 On the FastAPI side, it's fixed by https://github.com/tiangolo/fastapi/pull/5145 Given that I'll close this issue now. 🤓

I'm pretty sure that's part of the initial objective, to move to HTTPX instead of Requests. Given it's basically the same interface as Requests, I don't think there would be...

Thanks for all the input @dmontagu ! Impecable as always! :bowing_man: :clap:

I added a possible implementation in this PR https://github.com/python-trio/trio/pull/2160 --- I looked at the release notes and realized these names have been deprecated/replaced by other things: `run_sync_in_worker_thread` -> `to_thread.run_sync` `BlockingTrioPortal`...

Hehe, it seems there's a discrepancy in the types, not sure. I suspect the new types caught something not completely right. It probably needs an update in the types for...

Just some extra input: If the final solution ends up being plugin-based, I imagine the best way to go might be with APISpec, Marshmallow and maybe Webargs. If it's integrated...