Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature request: async api #134

Closed
sanzoghenzo opened this issue Nov 30, 2023 · 7 comments · Fixed by #146
Closed

feature request: async api #134

sanzoghenzo opened this issue Nov 30, 2023 · 7 comments · Fixed by #146

Comments

@sanzoghenzo
Copy link

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
Copy link
Contributor

amotl commented Dec 3, 2023

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
Copy link
Contributor

amotl commented Dec 3, 2023

urllib3 will stay in synchronous lands, so far?

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

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
Copy link
Author

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
Copy link
Collaborator

Ousret commented Dec 6, 2023

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
Copy link
Contributor

amotl commented Jan 8, 2024

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.

Footnotes

  1. Thanks, @Ousret.

@Ousret Ousret mentioned this issue Jan 9, 2024
5 tasks
@Ousret
Copy link
Collaborator

Ousret commented Jan 10, 2024

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

@sanzoghenzo
Copy link
Author

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants