aiohttp vs httpx2?
HTTPX2 – A next-generation HTTP client for Python
21–30 of 50 posts
Re: HTTPX2 – A next-generation HTTP client for Python
#22Noob question: what's the purpose of having so many request libraries? In JavaScript it's crazy, but in Python it's starting to feel the same: requests, httpx, httpx2... From my perspective, HTTP requests have been mastered for years (decades?). What's the point of switching libraries? What's so extraordinary about the new HTTP library that makes requests look crap? I understand that new protocols appear from time to…
HTTP is a pretty complex space once you get into the nitty-gritty of use-cases, common request handling patterns & conditional/dynamic header-definitions. In general this leads to:
- (a) built-ins (& some libraries) being very verbose to use because they tend to take a "fundamentals of HTTP" approach & not implement shortcuts/common patterns
- (b) libraries commonly falling into the trap of going the opposite direction & ending up with massive scope-creep and/or oversimplified, un-expressive APIs.
This leads to a churn of libraries due to developers yearning for a Goldilocks implementation in between.
Javascript tends to be ahead of other ecosystems in churn due to ease of library publishing, Python's catching up, but overall it's the same pattern in both.
---
Also, one big additional factor is async:
- NodeJS built-ins implemented a callback pattern just before promises took off, & have struggled to upgrade to promises cleanly without breaking backward compat.
- Python's got a similar story with various generations of http library being sync, or relying on different async approaches in confusing ways.
Re: HTTPX2 – A next-generation HTTP client for Python
#23Noob question: what's the purpose of having so many request libraries? In JavaScript it's crazy, but in Python it's starting to feel the same: requests, httpx, httpx2... From my perspective, HTTP requests have been mastered for years (decades?). What's the point of switching libraries? What's so extraordinary about the new HTTP library that makes requests look crap? I understand that new protocols appear from time to…
`requests` has a friendlier API than the standard library. However, it does not support newer versions of HTTP, nor does it support `async`. The maintainer considers it complete, feature-frozen software, IIRC - they'd rather keep it stable for existing users and let other libraries succeed it. `aiohttp` supports `async` but was never popular for non-async `httpx` supported newer HTTP versions and both async and non-a…
And why don't people use pycurl? Curl is the king of the hill...
Re: HTTPX2 – A next-generation HTTP client for Python
#24Earlier quoted context omitted.
`requests` has a friendlier API than the standard library. However, it does not support newer versions of HTTP, nor does it support `async`. The maintainer considers it complete, feature-frozen software, IIRC - they'd rather keep it stable for existing users and let other libraries succeed it. `aiohttp` supports `async` but was never popular for non-async `httpx` supported newer HTTP versions and both async and non-a…
And why don't people use pycurl? Curl is the king of the hill...
There are tradeoffs to the non-Python HTTP libraries like pycurl and pyreqwests, namely:
- Non-portability to alternative Python implementations or environments without the supporting C libraries
- Less visibility into the client internals (for debugging etc)
Re: HTTPX2 – A next-generation HTTP client for Python
#25I would been pleased to see this project named something else, maybe “httpx-ng” or “httpy” as I immediately link “http*2” with the obsolete http/2 protocol and not the httpx project.
By what definition is HTTP/2 considered obsolete? Are you suggesting it's been supplanted by H3? (FWIW I agree w/ your objection to the "httpx2" name.)
Yep. All HTTP/2 features are subsumed by HTTP/3 and all HTTP/2 deployments should be focusing their effort on moving to HTTP/3.
HTTP/2 is full of growing pains and fiddly kernel config for it to perform better than even HTTP/1.1.
Moving these dependencies into userland was the path that HTTP/3 took and it has proven itself through CDN and browser adoption for years now.
I’d go as far as to say that we need to reevaluate the event loops in nginx and elsewhere to assume UDP and HTTP/3 framing instead of TCP. There are gains to be had.
Re: HTTPX2 – A next-generation HTTP client for Python
#26Re: HTTPX2 – A next-generation HTTP client for Python
#27Earlier quoted context omitted.
By what definition is HTTP/2 considered obsolete? Are you suggesting it's been supplanted by H3? (FWIW I agree w/ your objection to the "httpx2" name.)
Yep. All HTTP/2 features are subsumed by HTTP/3 and all HTTP/2 deployments should be focusing their effort on moving to HTTP/3. HTTP/2 is full of growing pains and fiddly kernel config for it to perform better than even HTTP/1.1. Moving these dependencies into userland was the path that HTTP/3 took and it has proven itself through CDN and browser adoption for years now. I’d go as far as to say that we need to reevalu…
Hmm, I'd define that as "deprecated", not "obsolete". Many extant H2 deployments are stable and performant, and if they're eg fronted by an H3 CDN, the migration ROI might be questionable. /$.02
Re: HTTPX2 – A next-generation HTTP client for Python
#28Earlier quoted context omitted.
By what definition is HTTP/2 considered obsolete? Are you suggesting it's been supplanted by H3? (FWIW I agree w/ your objection to the "httpx2" name.)
Yep. All HTTP/2 features are subsumed by HTTP/3 and all HTTP/2 deployments should be focusing their effort on moving to HTTP/3. HTTP/2 is full of growing pains and fiddly kernel config for it to perform better than even HTTP/1.1. Moving these dependencies into userland was the path that HTTP/3 took and it has proven itself through CDN and browser adoption for years now. I’d go as far as to say that we need to reevalu…
HTTP/3 is fundamentally a different architecture than /2. To fully embrace it requires rethinking backend design significantly; just bumping a version number on HTTP without utilizing the intention of the spec is incorrect.
HTTP/1.x is not obsolete. It fills a very relevant request structure that most of the Internet still runs on.
Re: HTTPX2 – A next-generation HTTP client for Python
#29Earlier quoted context omitted.
And why don't people use pycurl? Curl is the king of the hill...
There are tradeoffs to the non-Python HTTP libraries like pycurl and pyreqwests, namely: - Non-portability to alternative Python implementations or environments without the supporting C libraries - Less visibility into the client internals (for debugging etc)
Thx!
Re: HTTPX2 – A next-generation HTTP client for Python
#30Earlier quoted context omitted.
By what definition is HTTP/2 considered obsolete? Are you suggesting it's been supplanted by H3? (FWIW I agree w/ your objection to the "httpx2" name.)
Yep. All HTTP/2 features are subsumed by HTTP/3 and all HTTP/2 deployments should be focusing their effort on moving to HTTP/3. HTTP/2 is full of growing pains and fiddly kernel config for it to perform better than even HTTP/1.1. Moving these dependencies into userland was the path that HTTP/3 took and it has proven itself through CDN and browser adoption for years now. I’d go as far as to say that we need to reevalu…
[dead]