RU version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
78% Positive
Analyzed from 677 words in the discussion.
Trending Topics
#http#libraries#httpx#async#com#python#https#library#amp#requests
Discussion (23 Comments)Read Original on HackerNews
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 time (like HTTP/2), but that's very rare. And if there are performance differences between two libraries, are they really that huge? Even if they are, 99% of people don't need that boost. What prevents someone from just improving the existing library's performance?
`aiohttp` supports `async` but was never popular for non-async
`httpx` supported newer HTTP versions and both async and non-async. However the maintainer decided to close all outside submissions, issues and discussions for personal reasons.
`httpx2` is a maintained fork of `httpx`
- Non-portability to alternative Python implementations or environments without the supporting C libraries
- Less visibility into the client internals (for debugging etc)
- (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.
(FWIW I agree w/ your objection to the "httpx2" name.)
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.
It's been a pleasure to use, has a httpx compatibility layer, and it's fast (https://github.com/MarkusSintonen/pyreqwest/blob/main/docs/b...)
“OpenAI: Migrating to HTTPX2” (github.com/openai)
66 points | 1 hour ago | 50 comments
https://news.ycombinator.com/item?id=49479566