The API was not a question of preference. If you look at most http lib APIs (python requests included), a single call returns a response object. My goal was to keep compatibility with this API to ease the migration effort, while baking in support for concurrent requests, which was the whole point of the lib.
There is no parallelism in that call btw. It's in the Readme. If it's http/2, it'll multiplex requests. If it's http/1, it'll try to pipeline, and if doesn't work, it'll fetch them one by one (with or without keep-alive). If they're different origins, the requests will be managed inside an event loop.
> Why not use composition instead?
You'll have to explain with an example of your own. However, there's already a ticket for implementing an event-based request handling, I just never prioritized it because no one asked for it yet, no one has shown interest in contributing, and frankly, I haven't needed it yet.
> Now you're stuck with this API forever.
It's still early 0.x days, so I might still remove APIs I don't think are future proof. That said, a lot of libs have lived with similar APIs all these years, and I don't see any reason for removing it.
Do you plan to support webmock and httplog ? Or add support for httpx into those ?
Can't integrate a networking lib that can't be mocked in my specs.
httpx also ships with its own request/response logger, set HTTPX_DEBUG=1 or set the options so that you see an example.
Any idea why the project is posted now? Is there a beta or RC release that’s significant?
responses = HTTPX.get("/page1").
get("/page2").
start
array = ["https://news.ycombinator.com/news", "https://news.ycombinator.com/news?p=2", "https://news.ycombinator.com/news?p=3"]
page1, page2, page3 = HTTPX.get(*array) *pages = HTTPX.get(*urls) urls = ['https://example.com/foo', 'https://example.com/bar']
HTTPX.get(*urls)Timeout does not help here - if the api is for concurrent requests, it's bad that caller cannot do anything before `(the slowest request finished || timeout exceeded)`.