I hope to one day see what I've wanted at times for almost 20 years: something a bit like requests as a low-entry-barrier API but that allows nearly optimal use

I hope to one day see what I've wanted at times for almost 20 years: something a bit like requests as a low-entry-barrier API but that allows nearly optimal use of the network for high-throughput scenarios too. Learn a few more API features to expand your use case, rather than having to discard it all and try some other completely different approach with completely different gotchas. But something that could be useful in data science scripts etc, not something special and dicey that only works with one carefully tuned application. A basic problem is that Python asyncio doesn't expose disk/filesystem IO. I think it would be so common that people are scripting an endpoint (rather than some network-to-network proxy) and so would need to easily write async/concurrency scenarios that source or sink from files while efficiently tying into this kind of high-throughput requests layer. It seems a bit much to expect one HTTP client library author to fix this core deficit in the Python platform. For high performance, you really need to balance disk IO and network IO and also avoid WAN pitfalls like synchronous HTTP/1.1 socket stalls. You need to embrace some kind of async or concurrency paradigm to specify request streams that can be pipelined without false inter-request dependencies. You also need to think about how to expose request or connection-level failures and allow sensible forms of retry within this logical request stream. It's kind of useless if it only supports toy/demo scenarios but cannot sustain high request throughput for hours or days in practice. Then, you also need some sensible flow-control to avoid stupid results like hundreds of concurrent HTTP/2 streams competing over one socket when it would be better to essentially serialize and pipeline them back-to-back with just a handful of in-flight requests necessary to fully stuff the WAN pipe. You want this limited concurrency for IO optimization and buffer management, to avoid thrashing your end systems. I think it would be better to have this as scheduling policies configured in the core API constructs, with some canned heuristics or self-adaptation. There should be some point of blocking/push-back to pace a naive application, rather than having some API which happily allows the naive application to push things past the breaking point. And over the WAN, you really need parallel TCP as well for high bandwidth. You can't declare that now with multiplexed HTTP/2 streams on one socket, there is no need for multiple sockets. It's important to have multiple TCP windows rather than one single window that needs to scale too far and be prone to collapse.