feature request: async api

[sanzoghenzo]

Hi there,

are there any plans to support/switch to an async client like httpx in place of requests?

It would be useful for using it within web services without blocking concurrency.

[amotl]

Dear Andrea,

thank you for writing in.

Are there any plans to support/switch to an async client like httpx in place of requests?

It isn't planned yet, but we will be happy to take it into consideration.

It would be useful for using it within web services without blocking concurrency.

We can see the need for such scenarios. Let's use this ticket to maybe collect more voices from the community about how strong the needs are beyond your initiative, which we appreciate.

an async client like httpx

We guess using httpx is the way to go on this matter? Are there any alternatives yet? urllib3 will stay in synchronous lands, so far?

With kind regards, Andreas.

/cc @hramezani

[amotl]

urllib3 will stay in synchronous lands, so far?

On this matter, it was easy to discover those discussions.

• https://github.com/urllib3/urllib3/issues/776
• https://github.com/urllib3/urllib3/issues/1323

Do you have any pragmatic recommendations for us, @hramezani?

• Wait for urllib3 version 3 to have full async support?
• Just use httpx?
• Use a different library?

[sanzoghenzo]

I've suggested httpx because it's my go-to library for async requests these days, but the trustworthy aiohttp is also an option. In comparison with aiohttp, though, httpx can be used both sycronously and asyncronously, and supports HTTP/2; by contrast, aiohttp is faster (but doesn't decode JSON automatically as requests and httpx do).

[Ousret]

Hello,

There's a 3rd option you may consider, staying with Requests but "upgrading" to https://github.com/jawah/niquests Happy to hear your opinion on the matter.

[amotl]

Hi again,

Niquests, advertising itself as a drop-in replacement for Requests, sounds intriguing [^1], so we would like to give it a spin. In order to evaluate interest within the community, please vote 👍 on the original post by @sanzoghenzo. At the same time, a corresponding pull request would be very much welcome.

With kind regards, Andreas.

[^1]: Thanks, @Ousret.

[Ousret]

Thank you for considering Niquests, I'd be happy to help and support the initiative. Let me know if you need anything.

[sanzoghenzo]

I can see the benefit of a drop in replacement, but since we're talking about switching to async, the drop-in replacement is only half of the sotry: all the methods of the AsyncSession and responses needs to be awaited, and the functions containing these calls needs to be in turn async.

Anyway, I no longer have the need for this request since I only needed a few endpoints, and I was a bit disappointed when I realized that there's no object de/serialization (using dataclasses, pydantic, attrs, msgspec...) in this library.

Feel free to close this if nobody else need an async version!

[amotl]

Hi again.

Yesterday, I stumbled upon the universalasync package. Is it something we could leverage here to swap out the proprietary implementation for having support for both sync and async?

I did not look into the details, and would like to defer the evaluation to @Ousret, if you can find the time?

Cheers, Andreas.

[Ousret]

If I got it right, this package does not generate async from the sync code. Rather, it simulate sync code based on the async one. By "simulate", I mean it start a thread and isolate a event loop. This will bring a huge overhead, and actually lower drastically the sync performance, I am rather sure that it will cause issue in multi-threaded environment... The approach we have, unfortunately, is still the best option we have to date.

regards,

[amotl]

Thank you very much for your assessment, when I wasn't able to find the time to do it properly. I absolutely agree, so I am closing this ticket again. 🙇