Migrating to HTTPX2 • Hacker News Board

Re: Migrating to HTTPX2

#51

Post by NewJazz » Fri, Aug 28, 2026, 2:41 PM UTC

kelvinjps10 wrote: post #37

networked wrote: post #14

Earlier quoted context omitted.

So I guess HTTPX2 ( https://github.com/pydantic/httpx2 ) is winning out over HTTPXYZ ( https://codeberg.org/httpxyz/httpxyz )? I didn't switch to HTTPXYZ after the fork but have been watching it. (What I did was use urllib.request more and bite the Rust bullet with wreq, https://github.com/0x676e67/wreq-python , where it wasn't enough.)

in their README >Important We started this fork because there was no activity on HTTPX, a very popular Python HTTP library. A few weeks later, Pydantic started their own fork called HTTPX2. We decided to embrace this and support HTTPX2. We're upstreaming our fixes to HTTPX2 and in our opinion it should be the "blessed" fork. Pydantic can make this more successful than we ever can. See also https://tildeweb.nl/~michie…

It is too bad because httpxyz is absolutely the better name.

Re: Migrating to HTTPX2

#52

Post by t098i3 » Fri, Aug 28, 2026, 2:43 PM UTC

portly wrote: post #25

superze wrote: post #24

Earlier quoted context omitted.

The issue with httpx is that it has an obnoxious and toxic maintainer.

What happened?

Read for yourself: https://github.com/encode/httpx/discussions/3784

They also effectively killed off MkDocs: https://github.com/mkdocs/mkdocs/discussions/3677

Re: Migrating to HTTPX2

#53

Post by awildfivreld » Fri, Aug 28, 2026, 2:47 PM UTC

ZeroCool2u wrote: post #42

The requests packages fundamental API is good enough and is now maintained by the PSF. I don't understand why OpenAI and Anthropic don't just throw some $$$ to the PSF for focused improvements and expansion of it.

The maintainers of requests have made it pretty clear that they consider that package feature complete, and have not showed interest in adding native async support to the core.

Re: Migrating to HTTPX2

#54

Post by KaiserPro » Fri, Aug 28, 2026, 2:47 PM UTC

fsuts wrote: post #36

[flagged]

because its over QUIC, which is different enough to be a pain.

Not that there is anything wrong with QUIC, at least its built by someone who knows what they are doing, unlike HTTP2

Re: Migrating to HTTPX2

#55

Post by KaiserPro » Fri, Aug 28, 2026, 2:49 PM UTC

Why would you want to use HTTPX2 over say requests?

Re: Migrating to HTTPX2

#56

Post by myshapeprotocol » Fri, Aug 28, 2026, 3:02 PM UTC

[dead]

Re: Migrating to HTTPX2

#57

Post by [deleted] » Fri, Aug 28, 2026, 3:03 PM UTC

portly wrote: post #25

superze wrote: post #24

Earlier quoted context omitted.

The issue with httpx is that it has an obnoxious and toxic maintainer.

What happened?

[deleted]

Re: Migrating to HTTPX2

#58

Post by awoimbee » Fri, Aug 28, 2026, 3:08 PM UTC

jklehm wrote: post #49

Wonder if they evaluated httpx2 vs niquests: https://github.com/jawah/niquests

I opened an issue some time ago about them monkey patching urllib3, it was fixed than but I now see the issue has been outright deleted. Oh and now I see there is a URLLIB3_NO_OVERRIDE thing... I would not recommend this project.

Re: Migrating to HTTPX2

#59

Post by jtbaker » Fri, Aug 28, 2026, 3:21 PM UTC

jklehm wrote: post #49

Wonder if they evaluated httpx2 vs niquests: https://github.com/jawah/niquests

Same! Recently ported some code from httpx -> niquests and the experience has been good, although admittedly the governance of the project seems a little unclear.

I (ok, Qwen 3.7 27B) wrote some benchmarking code to compare throughput, and niquests seems to be substantially more performant for traffic that doesn't need to traverse the public web, e.g. intra cluster service to service communication:

https://gist.github.com/jtbaker/61061d27949ef48ac31e85ff28c2...

uv run scripts/bench_http.py --count 1000 Benchmarking 1000 requests to http://localhost:8000/health (concurrency=16, timeout=30.0s) Date: 2026-08-28T10:18:34.480111

Running httpx... Running httpx2... Running niquests...

Metric httpx httpx2 niquests ------------------------------------------------------- mean 17.8ms 4.6ms 3.3ms min 3.2ms 1.5ms 1.2ms max 632.4ms 11.1ms 10.8ms p50 15.9ms 4.2ms 3.0ms p95 32.4ms 7.4ms 5.6ms p99 52.1ms 8.5ms 8.4ms total 1.15s 315.5ms 239.7ms throughput 869.2 req/s 3170.0 req/s 4171.1 req/s

Winner: niquests (4.8x faster by wall clock)

Re: Migrating to HTTPX2

#60

Post by tankenmate » Fri, Aug 28, 2026, 3:21 PM UTC

KaiserPro wrote: post #54

fsuts wrote: post #36

[flagged]

because its over QUIC, which is different enough to be a pain. Not that there is anything wrong with QUIC, at least its built by someone who knows what they are doing, unlike HTTP2

that's not really much of an argument, almost all reasonable libraries wrap the functionality.and if a provider doesn't want to support http3 then the library will fallback, and then the laggards should pay the slow tax.