Anthropic made the same change a few weeks after OpenAI did: <a href="https://github.com/anthropics/anthropic-sdk-python/releases/tag/v1.0.0" rel="nofollow">https://github.com/anthropics/anthropic-sdk-python/releases/...</a><p>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.<p>The httpx2 project is essentially a fork that promises <i>not</i> to break the existing API, which makes it a more stable dependency to build against.<p>I wrote a pretty long comment about my concerns for the breaking 1.0 version last year - <a href="https://github.com/encode/httpx/discussions/3344#discussioncomment-14170874" rel="nofollow">https://github.com/encode/httpx/discussions/3344#discussionc...</a> - 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 <i>keeps</i> the old API.
> 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.<p>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.<p>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.
HTTPX stable hasn't had a release since December 2024, but there have been two dev releases of the 1.0 branch this month (after a gap since September 2025.)<p>Unfortunately that 1.0 work is happening in a private repository.<p><a href="https://pypi.org/project/httpx/#history" rel="nofollow">https://pypi.org/project/httpx/#history</a>
> Unfortunately that 1.0 work is happening in a private repository.<p>That’s even more reason to consider it non-viable.<p>There is no reason to encourage or support this type of behavior in a project. It is their right to do with it as they please, but I’m not interested in a project that functions like this. The forks are continuing to operate like true community projects.
unbelievable, how can a single person affect negatively FOSS so much?<p>I mean really, closing repos? excluding maintainers? committing only on private repos?<p>This type of behavior should be moderated and banned from any FOSS activity to avoid exactly this situation of becoming a liability.<p>I've never seen a open source project page without a github link or a git clone ref like this <a href="https://www.encode.io/hx/" rel="nofollow">https://www.encode.io/hx/</a> it is so ridiculous, wasn't that stuff on github? and isn't it anyway there due to over 1k forks?<p>what's the advantage of having this behavior? I see it only damaging towards the person, the project and the community.
The issue with httpx is that it has an obnoxious and toxic maintainer.
What happened?
Read for yourself: <a href="https://github.com/encode/httpx/discussions/3784" rel="nofollow">https://github.com/encode/httpx/discussions/3784</a><p>They also effectively killed off MkDocs: <a href="https://github.com/mkdocs/mkdocs/discussions/3677" rel="nofollow">https://github.com/mkdocs/mkdocs/discussions/3677</a>
That's easily the strangest self-destruction I've ever seen. "Skewed gender representation"? Not sure how that matters or what the intended effect of salting the earth here was.
I feel like that hardly answers anything
Can’t understand how so many otherwise cognitively able people refuse to acknowledge gender dysphoria as the mental illness it (often) is. As a non-US person, is this what woke means?
was probably chewing bubble gum on the wrong sidewalk
So I guess HTTPX2 (<a href="https://github.com/pydantic/httpx2" rel="nofollow">https://github.com/pydantic/httpx2</a>) is winning out over HTTPXYZ (<a href="https://codeberg.org/httpxyz/httpxyz" rel="nofollow">https://codeberg.org/httpxyz/httpxyz</a>)? 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, <a href="https://github.com/0x676e67/wreq-python" rel="nofollow">https://github.com/0x676e67/wreq-python</a>, where it wasn't enough.)
in their README
>Important<p>We started this fork because there was no activity on HTTPX, a very popular Python HTTP library.<p>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.<p>See also <a href="https://tildeweb.nl/~michiel/httpx2.html" rel="nofollow">https://tildeweb.nl/~michiel/httpx2.html</a><p>Thanks for all your support!<p>Sander & Michiel
httpx2 is sponsored by Pydantic and has involvement from the new maintainer of Starlette, so it's off to a very strong start.
"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"<p>wtf is going on
A bit strange considering "coding is solved".<p>But seriously, migrating between different libs should be ~free for both Anthropic and OpenAI.
[flagged]
The Python community loves confusing versioning.<p>I mean, obviously Python 2.7 is newer than Python 3.1<p>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).
That isn't confusing at all, if you know how maintained stable releases work.<p>Happens with the Linux kernel as well.
There are a lot of large projects where X.1 is newer than Y.0. You release a new major version for breaking changes, but you backport security changes to previous major releases as well.
Just read <a href="https://semver.org/" rel="nofollow">https://semver.org/</a>
Isn't that whole point of semantic release?<p>Minors and hotfixes allow you to release a new version for an older release (like if you released 3.7 but you found a bug present in 3.4, you can release 3.4.1 which would be newer than 3.7), making it possible to have multiple supported versions at the same time.
Tangibly related, did you know that odd versions of node don't get LTS, I found it odd at first
That’s probably the worst example you could have chosen.<p>You shouldn’t assume anything about relative date of 2.7 and 3.1.
Wonder if they evaluated httpx2 vs niquests: <a href="https://github.com/jawah/niquests" rel="nofollow">https://github.com/jawah/niquests</a>
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.<p>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:<p><a href="https://gist.github.com/jtbaker/61061d27949ef48ac31e85ff28c24eb6" rel="nofollow">https://gist.github.com/jtbaker/61061d27949ef48ac31e85ff28c2...</a><p>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<p>Running httpx...
Running httpx2...
Running niquests...<p>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<p>Winner: niquests (4.8x faster by wall clock)
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.
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.<p>yeah nice engineering clowns
There seems to be a bunch of downsides mentioned...<p>But what are the upsides of this change?
[flagged]
It's like that time I started a primary school and then closed it because I hated that the overwhelming majority of employees were women.
Did this move improve the ratio of gender representation in the software development community?
This has happened in many packages contributed to by this person. Mkdocs e.g
unbelievable, how can a single person affect negatively FOSS so much?<p>I mean really, closing repos? excluding maintainers? committing only on private repos?<p>This type of behavior should be moderated and banned from any FOSS activity to avoid exactly this situation of becoming a liability.<p>I've never seen a open source project page without a github link or a git clone ref like this <a href="https://www.encode.io/hx/" rel="nofollow">https://www.encode.io/hx/</a> it is so ridiculous, wasn't that stuff on github? and isn't it anyway there due to over 1k forks?<p>what's the advantage of having this behaviour? I see it only damaging towards the person, the project and the community.
Oh boy, no wonder MkDocs became an absolute shit-show that fucked everyone over... <a href="https://github.com/mkdocs/mkdocs/discussions/4077#discussioncomment-15687765" rel="nofollow">https://github.com/mkdocs/mkdocs/discussions/4077#discussion...</a>
That’s fair, good for the maintainer to consider his personal values with regards to projects he wants to spend his time on
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.
i assume this is largely about the cybersecurity blitz, to ensure hot-path code is secure?
Why this is in the frontpage?
I'd second this question. And I really mean that in a sincere way. Why is the choice of a random HTTP library in an SDK such an engaging topic of discussion here? Is there some context I'm missing?<p>When I first read the title, I assumed this was some fancy new protocol that extends HTTP or something. But it's just about an SDK switching one transitive dependency with a fork? And arguably one that should just have its functionality be part of stdlib?
nb: operating system TLS trust store is used now (instead of certifi)
Better migrate to <a href="https://zapros.dev" rel="nofollow">https://zapros.dev</a> from httpx maintainer
Why would you want to use HTTPX2 over say requests?
Why is everyone so slow to move to http3?
HTTPX2 isn't about the protocol version, it's the name of a python library to make http requests.<p>But yes, it doesn't support HTTP3. Here's the related issue: <a href="https://github.com/pydantic/httpx2/issues/92" rel="nofollow">https://github.com/pydantic/httpx2/issues/92</a>
Why would you assume that we have to move from techX to techX+1? If I release http4 would you assume that you have to migrate to http4 at some point?
because its over QUIC, which is different enough to be a pain.<p>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.
Oh, well... It was bound to happen eventually. I suppose there must be some advantages to such a solution.
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<p><a href="https://pyqwest.dev" rel="nofollow">https://pyqwest.dev</a>
Wow, finally...
[dead]
[flagged]
[flagged]
[dead]
[dead]
[dead]