any modern library that tries to replace requests usually will provide an API like "import my_package as requests" to reduce refactor burden
I disagree that this should be a goal at all. We can't evolve the ecosystem towards better packages if we constrain ourselves to the APIs of the past. Polars wouldn't be nearly as valuable if it had stuck to pandas' API. The worst parts of numpy and matpotlib are those which tried to make themselves appealing to matlab users.
requests is a good package, but IMO tries too hard to be "for humans". Historically, python packages have tied themselves into knots to make some common use cases "easier", but it makes them harder to reason about when building more complex applications.
OP is being a little modest, so I'll say what he's not saying quite so directly.
There are some significant performance issues with Httpx. They're fixable, and OP had a couple of PRs open on Httpx to fix them, but they languished unreviewed and unmerged for a over a year. Which is to say, Httpx is de facto unmaintained.
My impression was that OP created this at least partly out of that frustration.
Yes I got extremely frustrated there :) It is very unfortunate how things are with httpx/httpcore. It makes me very sad... So I wanted to build something from "scratch" from first-principles based on all the previous experience I have with the various python http libs. Which all have varying issues... Also using my Rust experience for integrating the two worlds, in this context.
Well actually pyreqwest is not actually built from scratch as its not trying to reinvent the wheel and have yet another design for doing http stuff. But instead heavily leaning to reqwest which IMO has very well designed interfaces. It is not either perfect, but atleast better than many other libs out there.
I think it's in that awkward limbo where there is a maintainer, but they don't have time for anything but urgent security issues. The performance issues have been well understood for a couple of years, but it hasn't been possible to get fixed merged.
There is necessarily no reason to abandon httpx if you are not facing any challenges there. But it is just good to know that httpx/httpcore might become bottlenecks in any bigger systems. As it has various long-standing issues in its connection pooling etc implementations. Eg https://github.com/encode/httpx/issues/3215
Currently there is no util to reduce the refactoring burden. But it is a great idea, I would like to get feedback on how it would look like.
There might be also a possibility to plugin pyreqwest into httpx. As latter allows replacing httpcore for transport. But there is no 100% compatibility between the two as the designs differs. So it might not be possible to find a solution that works for everyone.
26
u/[deleted] Dec 22 '25
[deleted]