-
-
Notifications
You must be signed in to change notification settings - Fork 9.7k
Description
Hello, I do know that ‘Requests is not accepting feature requests at this time.´ but I’d still like to propose something, and be willing to implement it myself if it actually sounds like a decent feature.
It is true that Requests is usually the way to go, and it’s KISS api make it imo the best choice for either small scripts or complex projects, so I totally understand the will to keep it as-is. However, there is one thing that is still not available, and it is async support.
I’ve seen this has been quite discussed in #1390, and it’s currently recommend to use grequests for async operations. But I think this library could actually provide async support in a more straightforward way:
aget,apost,apatchetc methods could be provided, so the existing method wouldn’t change, but calling those would return a coroutine instead. Most of the logic would stay the same, only the http calls would be asynchronous. This is similar to how async db operations have been added to Django:All QuerySet methods that cause an SQL query to occur have an a-prefixed asynchronous variant.- Those would use urllib3.future, if not available an exception would get raised. As such, we are still fully compatible with existing dependencies for synchronous operations, urllib3.future is only needed if the new async methods are used.
I do know the chances of this feature getting accepted are pretty low, even so considering that it would rely on urllib3.future, so:
- If this sounds actually decent, I can provide a basic PoC and iterate on it
- Otherwise I’ll just fork Requests with that feature as I still think that would be helpful to enough people
Thanks