Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Why would you want to use HTTPX2 over say requests?
    by KaiserPro
  • async
    by oersted
  • Since it clearly intends to satisfy the async use case, I wish you'd've phrased this as "over aiohttp".
    by deathanatos
  • You probably want to use pretty much anything over requests for performance reasons.
    by imp0cat
  • Async. And it comes with WSGI and ASGI transport adapters [1], which are amazing for testing/debugging with the client and server in a single process. And I personally find the httpx API is much cleaner and more composable, but ymmv.

    [1] https://www.python-httpx.org/advanced/transports/#wsgi-trans...

    by 12_throw_away
  • Requests has been dead for over a decade. It doesn’t support HTTP/2, it doesn’t support HTTP/3, it doesn’t support async, and they ignore security vulnerabilities for months.

    Nobody should use requests. If you are still using it, the quickest way to get off it is to switch to niquests, which is actively developed, supports all the things I mentioned above, and API-compatible with requests - you can just do `import niquests as requests` for an instant upgrade.

    https://niquests.readthedocs.io/

    by JimDabell
  • Oh, well... It was bound to happen eventually. I suppose there must be some advantages to such a solution.
    by ironqcold
  • A network error occurred. Please check your connection and try again. If this issue persists please contact us through our help center at help.openai.com.

    yeah nice engineering clowns

    by i574n
  • nb: operating system TLS trust store is used now (instead of certifi)
    by tosh
  • what's `nb` ?
    by hmokiguess
  • Ugh. certifi the most annoying thing ever. It snuck into numerous python dependencies, never made anything better, and confuses all the junior devs when their venvs/containers etc can't access internal CA signed resources. Probably have explained what to do over 9,000 times. And for what? "To provide updated root CAs". Meh. I don't need daily CA trust store updates. If your CA roots are that new, I want nothing to do with it. Cert issuers (cough sectigo and their amateur hour CA root rotation recently, not even Mozilla had it).
    by skullone
  • This could be a breaking change (for some corporate network environments).
    by zx8080
  • All this for an SDK you might not need.

    SDK is just a wrapper around POST https://api.openai.com/v1/responses

    Just REST + JSON.

    streaming (sse parsing) + tool calling + structured outputs + pagination are easy to do.

    by tulio_ribeiro
  • There seems to be a bunch of downsides mentioned...

    But what are the upsides of this change?

    by londons_explore
  • You no longer need to jump through the hoops in order to support your own root CA
    by kova12
  • https://github.com/encode/httpx/discussions/3784

    > I've closed off access to issues and discussions.

    > I don't want to continue allowing an online environment with such an absurdly skewed gender representation. I find it intensely unwelcoming, and it's not reflective of the type of working environments I value.

    https://www.reddit.com/r/Python/comments/1rl5kuq/anyone_know...

    by ddorian43
  • we have recently switched from httpx for the same reason but instead went with the Rust-based pyqwest (runs on Hyper) it has also a drop-in httpx-compatible transport so migration was easy and also it supports http2 trailers

    https://pyqwest.dev

    by ushakov
  • Why not pyreqwest?
    by sirfz
  • Wonder if they evaluated httpx2 vs niquests: https://github.com/jawah/niquests
    by jklehm
  • httpx2 is fork maintained by pydantic which are trustworthy and resourcefull maintainers.
    by jelenzelen
  • 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.
    by awoimbee
  • 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)

    by jtbaker
  • Anthropic made the same change a few weeks after OpenAI did: https://github.com/anthropics/anthropic-sdk-python/releases/...

    The problem with httpx as a dependency is that it's currently working towards a 1.0 release which will be full of breaking changes.

    The httpx2 project is essentially a fork that promises not to break the existing API, which makes it a more stable dependency to build against.

    I wrote a pretty long comment about my concerns for the breaking 1.0 version last year - https://github.com/encode/httpx/discussions/3344#discussionc... - in that comment I recommended the HTTPX project release their 1.0 as a package called httpx2 instead, but a year later we now have an httpx2 (released by a different maintainer) that keeps the old API.

    by simonw
  • The Python community loves confusing versioning.

    I mean, obviously Python 2.7 is newer than Python 3.1

    I remember swearing I would never migrate to python3 but here we are, I migrated without even feeling it or realizing when (But I do remember django played a big role).

    by rolymath
  • Biggest problem with httpx I see is authors sanity https://github.com/encode/httpx/discussions/3784. I do not even understand what is his problem (too much or too little woke internet?).
    by jelenzelen
  • A bit strange considering "coding is solved".

    But seriously, migrating between different libs should be ~free for both Anthropic and OpenAI.

    by krzyk
  • 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.)
    by networked
  • "I recommended the HTTPX project release their 1.0 as a package called httpx2 instead, but a year later we now have an httpx2 (released by a different maintainer) that keeps the old API"

    wtf is going on

    by tonyhart7
  • The issue with httpx is that it has an obnoxious and toxic maintainer.
    by superze
  • > The problem with httpx as a dependency is that it's currently working towards a 1.0 release which will be full of breaking changes.

    The httpx maintainer closed off access to issues and discussions on the repo, has been ignoring PRs, and hasn’t updated it in a half a year.

    I don’t think there is any reason to consider httpx as a viable project any more. The Pydantic httpx fork has taken its place.

    by Aurornis