5 ms·

HTTPX2 – A next-generation HTTP client for Python

132 points by tosh 2mo ago

WalterGR 2mo ago
Also see the user’s other submission https://news.ycombinator.com/item?id=49477212 https://news.ycombinator.com/item?id=49477212 “OpenAI: Migrating to HTTPX2” (github.com/openai) 66 points | 1 hour ago | 50 comments
jenders 2mo ago
I 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.
- brainzap 2mo ago
  I agree, the brain built in error correction makes it harder to read
- chrisweekly 2mo ago
  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.)
  - jenders 2mo ago
    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.
    - chrisweekly 2mo ago
      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
      - jenders 2mo ago
        Context: spent my career building CDNs at Cloudflare/facebook/pinterest. The h3 juice is worth the squeeze. 0rtt TLS, BBR, HPACK, etc. You can roughly achieve this with a carefully configured h2 deployment across multiple layers and packages or just move to h3 and let the app layer handle it all. We baked all of the best practices into h3, the world just needs to move on.
    - tcdent 2mo ago
      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.
      - jenders 2mo ago
        Seems like the major gripe is over my usage of the word “obsolete” instead of “deprecated”. We could all be flipping switches instead of tapping on MacBooks but you gotta draw a line somewhere.
    - 7bit 2mo ago
      [dead]
- theanonymousone 2mo ago
  httpy is actually twofold cool for a Python HTTP client!
  - jenders 2mo ago
    Agreed! I love naming things :D
- auvi 2mo ago
  Ruby has httparty. https://github.com/jnunemaker/httparty https://github.com/jnunemaker/httparty
- Lindby 2mo ago
  There is already a popular project called httpie, so httpy would be really confusing in non written form. Beside that, i completely agree, the name could be better. https://httpie.io/ https://httpie.io/
casper14 2mo ago
People should be aware how much worse HTTPX performs versus Aiohttp. For high scale systems it makes a massive difference
- nateb2022 2mo ago
  pyreqwest has been delightful so far: https://github.com/MarkusSintonen/pyreqwest https://github.com/MarkusSintonen/pyreqwest It's been a pleasure to use, has a httpx compatibility layer, and it's fast (https://github.com/MarkusSintonen/pyreqwest/blob/main/docs/benchmarks.md https://github.com/MarkusSintonen/pyreqwest/blob/main/docs/b...)
- qurren 2mo ago
  I keep confusing aiortc and aoc
- NewJazz 2mo ago
  AIUI the fork has better performance.
- ranger_danger 2mo ago
  I searched and searched for way too long and could not find any information on whether or not aiohttp supports HTTP/2 or 3... do you know or have any reference that explains what all is supported?
  - t098i3 2mo ago
    It does not: https://github.com/aio-libs/aiohttp/issues/5999 https://github.com/aio-libs/aiohttp/issues/5999
- greatgib 2mo ago
  I can attest of that, and in addition of harmful decisions of the maintainer that are loaded foot guns...
- andrewmcwatters 2mo ago
  [dead]
BoumTAC 2mo ago
Noob 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 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?
- t098i3 2mo ago
  `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-async. However the maintainer decided to close all outside submissions, issues and discussions for personal reasons. `httpx2` is a maintained fork of `httpx`
  - BoumTAC 2mo ago
    Thanks for the explanation !
  - lofaszvanitt 2mo ago
    And why don't people use pycurl? Curl is the king of the hill...
    - t098i3 2mo ago
      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)
vivzkestrel 2mo ago
aiohttp vs httpx2?
- WalterGR 2mo ago
  https://news.ycombinator.com/item?id=49478655 https://news.ycombinator.com/item?id=49478655 https://news.ycombinator.com/item?id=49479566 https://news.ycombinator.com/item?id=49479566
igkougkousis 2mo ago
[flagged]
deleted 2mo ago
[deleted]
niltecedu 2mo ago
Everytime someone is using httpx I always wonder why use that especially when niquests exists? I feel like it has always been such a better package
x1colegal 2mo ago
Cool project bro
dethos 2mo ago
HTTPX2 isn't a great name for a fork (or at all). Just leads to more confusion. Nevertheless, I'm curious about the pros and cons when comparing with "niquests".
cbsmith 2mo ago
I thought we all moved over to Niquests and/or aiocquic and HTTP/3 these days.

132 points by tosh 2mo ago

Also see the user’s other submission https://news.ycombinator.com/item?id=49477212 https://news.ycombinator.com/item?id=49477212 “OpenAI: Migrating to HTTPX2” (github.com/openai) 66 points | 1 hour ago | 50 comments

jenders 2mo ago

I 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.

brainzap 2mo ago
I agree, the brain built in error correction makes it harder to read
chrisweekly 2mo ago
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.)
- jenders 2mo ago
  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.
  - chrisweekly 2mo ago
    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
    - jenders 2mo ago
      Context: spent my career building CDNs at Cloudflare/facebook/pinterest. The h3 juice is worth the squeeze. 0rtt TLS, BBR, HPACK, etc. You can roughly achieve this with a carefully configured h2 deployment across multiple layers and packages or just move to h3 and let the app layer handle it all. We baked all of the best practices into h3, the world just needs to move on.
  - tcdent 2mo ago
    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.
    - jenders 2mo ago
      Seems like the major gripe is over my usage of the word “obsolete” instead of “deprecated”. We could all be flipping switches instead of tapping on MacBooks but you gotta draw a line somewhere.
  - 7bit 2mo ago
    [dead]
theanonymousone 2mo ago
httpy is actually twofold cool for a Python HTTP client!
- jenders 2mo ago
  Agreed! I love naming things :D
auvi 2mo ago
Ruby has httparty. https://github.com/jnunemaker/httparty https://github.com/jnunemaker/httparty
Lindby 2mo ago
There is already a popular project called httpie, so httpy would be really confusing in non written form. Beside that, i completely agree, the name could be better. https://httpie.io/ https://httpie.io/

casper14 2mo ago

People should be aware how much worse HTTPX performs versus Aiohttp. For high scale systems it makes a massive difference

nateb2022 2mo ago
pyreqwest has been delightful so far: https://github.com/MarkusSintonen/pyreqwest https://github.com/MarkusSintonen/pyreqwest It's been a pleasure to use, has a httpx compatibility layer, and it's fast (https://github.com/MarkusSintonen/pyreqwest/blob/main/docs/benchmarks.md https://github.com/MarkusSintonen/pyreqwest/blob/main/docs/b...)
qurren 2mo ago
I keep confusing aiortc and aoc
NewJazz 2mo ago
AIUI the fork has better performance.
ranger_danger 2mo ago
I searched and searched for way too long and could not find any information on whether or not aiohttp supports HTTP/2 or 3... do you know or have any reference that explains what all is supported?
- t098i3 2mo ago
  It does not: https://github.com/aio-libs/aiohttp/issues/5999 https://github.com/aio-libs/aiohttp/issues/5999
greatgib 2mo ago
I can attest of that, and in addition of harmful decisions of the maintainer that are loaded foot guns...
andrewmcwatters 2mo ago
[dead]

BoumTAC 2mo ago

Noob 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 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?

t098i3 2mo ago
`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-async. However the maintainer decided to close all outside submissions, issues and discussions for personal reasons. `httpx2` is a maintained fork of `httpx`
- BoumTAC 2mo ago
  Thanks for the explanation !
- lofaszvanitt 2mo ago
  And why don't people use pycurl? Curl is the king of the hill...
  - t098i3 2mo ago
    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)

vivzkestrel 2mo ago

aiohttp vs httpx2?

WalterGR 2mo ago
https://news.ycombinator.com/item?id=49478655 https://news.ycombinator.com/item?id=49478655 https://news.ycombinator.com/item?id=49479566 https://news.ycombinator.com/item?id=49479566

igkougkousis 2mo ago

[flagged]

deleted 2mo ago

[deleted]

niltecedu 2mo ago

Everytime someone is using httpx I always wonder why use that especially when niquests exists? I feel like it has always been such a better package

x1colegal 2mo ago

Cool project bro

dethos 2mo ago

HTTPX2 isn't a great name for a fork (or at all). Just leads to more confusion. Nevertheless, I'm curious about the pros and cons when comparing with "niquests".

cbsmith 2mo ago

I thought we all moved over to Niquests and/or aiocquic and HTTP/3 these days.