Auto-detect concurrency backend based on the async environment

Currently, if users want to run HTTPX on trio they need to manually pass a TrioBackend to the AsyncClient:

import trio
import httpx
from httpx.concurrency.trio import TrioBackend

async def main():
    async with httpx.AsyncClient(backend=TrioBackend()) as client:
        ...

trio.run(main)

On the other hand, running on asyncio doesn’t require passing any backend argument, which is a better user experience we’d like to have in all cases.

We should allow AsyncClient() to auto-detect the async environment it’s running in, and use the appropriate backend — and make that the default behavior, instead of asyncio.

Implementation ideas:

• Create a get_default_concurrency_backend() utility in utils.py. Detecting the async library in use can be done using sniffio. If no backend is available, raise an appropriate exception. (For example, this should currently be the case if we tried to run on curio, since we don’t have a CurioBackend.)
• Use this utility in all places where we currently default to AsyncioBackend as a backend, e.g. AsyncClient, ConnectionPool, etc.

[tomchristie]

Ah s’all good. The important thing from my POV is that we make sure we’re communicating and learning between ourselves - I’m seeing such a positive and constructive attitude on all sides, and yeah I totally dig that sometimes it’s easier to just demonstrate first.

There’s plenty of difficult trade-offs wrt. maturing the async ecosystem in Python - what I’m really appreciating at the moment is that I’m seeing a healthy respect for different folks taking different tacks onto helping be part of that.

[pquentin]

I agree! @njsmith and I should have spent more time explaining why we’re continuing the work on our urllib3 branch, and I hope we’ll be able to do this in the next few days.

Oops! More than one month has passed by. @njsmith told me he would like to write a proper comparison at some point, but that takes time and energy. I certainly find it mentally taxing to explain why I prefer to contribute to project A and not project B, when the two projects have similar goals!

I know Nathaniel has some technical reasons that I would not be able to explain well. So this will only be part of the story, but I can explain why I am working on the urllib3 fork since January 2018: I don’t want to waste the huge amount of real world experience urllib3 has. It seems wasteful to have to relearn this by waiting for a slow trickle of bug reports. In fact much of my work on the fork has been upstreamed (here’s a recent example) and this code now benefits the millions of urllib3 downloads that happen every day. And we continue to merge the changes made in urllib3 itself regularly, and all the sync tests for the core library actually pass, so we’ll soon be able to focus on improving the async support.