Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I forked httpx

tildeweb.nl

Post reply on HN
Print view View original

91–100 of 194 posts

Re: Why I forked httpx

#91

Post by xnorswap »

pjc50 wrote: post #62
maccard wrote: post #29

Earlier quoted context omitted.

> Then I found out it was broken. I contributed a fix. The fix was ignored and there was never any release since November 2024. This seems like a pretty good reason to fork to me. > Sending HTTP requests is a basic capability in the modern world, the standard library should include a friendly, fully-featured, battle-tested, async-ready client. But not in Python, Or Javascript (well node), or golang (http/net is _wors…

> dotnet's HttpClient is... fine. Yes, and it's in the standard library (System namespace). Being Microsoft they've if anything over-featured it.

It's fine but it's sharp-edged, in that it's recommended to use IHttpClientFactory to avoid the dual problem of socket exhaustion ( if creating/destroying lots of HttpClients ) versus DNS caching outliving DNS ( if using a very long-lived singleton HttpClient ).

And while this article [1] says "It's been around for a while", it was only added in .NET Framework 4.5, which shows it took a while for the API to stabilise. There were other ways to make web requests before that of course, and also part of the standard library, and it's never been "difficult" to do so, but there is a history prior to HttpClient of changing ways to do requests.

For modern dotnet however it's all pretty much a solved problem, and there's only ever been HttpClient and a fairly consistent story of how to use it.

[1] https://learn.microsoft.com/en-us/dotnet/core/extensions/htt...

Re: Why I forked httpx

#92

Post by samset7 »

mesahm wrote: post #4

the http landscape is rather scary lately in Python. instead of forking join forces... See Niquests https://github.com/jawah/niquests I am trying to resolve what you've seen. For years of hard work.

We have switched to niquests in my company and yes I can confirm that it's 10x better than httpx :)

Re: Why I forked httpx

#93

Post by sgt »

greatgib wrote: post #10
mesahm wrote: post #4

the http landscape is rather scary lately in Python. instead of forking join forces... See Niquests https://github.com/jawah/niquests I am trying to resolve what you've seen. For years of hard work.

The basis of httpx is not very good at all. I think that it owes its success to be first "port" of python requests to support async, that was a strong need. But otherwise it is bad: API is not that great, performance is not that great, tweaking is not that great, and the maintainer mindset is not that great also. For the last point, few points were referenced in the article, but it can easily put your production proj…

I literally the other week had the choice between using requests and httpx. I chose httpx after deliberating a bit. I don't need async capabilities right now but I figured it'll be more consistent if that changes later.

Re: Why I forked httpx

#94

Post by mesahm »

samset7 wrote: post #92
mesahm wrote: post #4

the http landscape is rather scary lately in Python. instead of forking join forces... See Niquests https://github.com/jawah/niquests I am trying to resolve what you've seen. For years of hard work.

We have switched to niquests in my company and yes I can confirm that it's 10x better than httpx :)

nice to hear :)

Re: Why I forked httpx

#95

Post by mesahm »

mananaysiempre wrote: post #80
mesahm wrote: post #4

the http landscape is rather scary lately in Python. instead of forking join forces... See Niquests https://github.com/jawah/niquests I am trying to resolve what you've seen. For years of hard work.

No Trio support yet, right? That’s the main reason to use httpx for me at least, and has been since I first typed “import httpx” some years ago. (Also the sponsorship subscription thing in the readme gives me vague rugpull vibes. Maybe I’ve just been burned too much—I don’t mean to discourage selling support in general.)

help for getting it working is appreciated, we have it in mind. duly noted about the sponsorship, we accept constructive criticism, and alternative can be considered.

Re: Why I forked httpx

#96

Post by duskdozer »

matheusmoreira wrote: post #82
Kwpolska wrote: post #25

What is it about Python that makes developers love fragmentation so much? Sending HTTP requests is a basic capability in the modern world, the standard library should include a friendly, fully-featured, battle-tested, async-ready client. But not in Python, stdlib only has the ugly urllib.request, and everyone is using third party stuff like requests or httpx, which aren't always well maintained. (See also: packaging)

Everybody's got a different idea of what it means for a library to be "friendly" and "fully-featured" though. It's probably better to keep the standard library as minimal as possible in order to avoid enshrining bad software. Programming languages could have curated "standard distributions" instead that include all the commonly used "best practice" libraries at the time.

https://xkcd.com/927/

Re: Why I forked httpx

#97

Post by [deleted] »

Yokohiii wrote: post #65
cachius wrote: post #53

Earlier quoted context omitted.

This is not merely open-source, but taking part in a huge package ecosystem in a foundational role in an XKCD 2347 type of way for HTTP requests. Put your side project on your personal homepage and walk away - fine. Make it central infrastructure - respond to participants or extend or cede maintainership.

I guess frustration speaks here? There is simply no responsibility an OSS maintainer has. They can choose to be responsible, but no one can force them. Eventually OSS licensing is THE solution at heart to solve this problem. Maintainers go rogue? Fork and move on. But surprise, who is going to fork AND maintain? Filling in all the demands from the community, for potentially no benefit? No one can force him to take th…

[deleted]

Re: Why I forked httpx

#98

Post by mesahm »

u_sama wrote: post #70
mesahm wrote: post #18

Earlier quoted context omitted.

ahah, "en effet"! je m'en souviendrai. more seriously, all that is needed is our collective effort. I've done my part by scarifying a lot of personal time for it.

I saw there are almost no bugs or things to contribute, are there other ways to help ?

yes, plenty! testing it extensively, finding edge bugs, (...) and of course: spread the word on other project to help increasing adoption.

Re: Why I forked httpx

#99

Post by [deleted] »

Yokohiii wrote: post #65
cachius wrote: post #53

Earlier quoted context omitted.

This is not merely open-source, but taking part in a huge package ecosystem in a foundational role in an XKCD 2347 type of way for HTTP requests. Put your side project on your personal homepage and walk away - fine. Make it central infrastructure - respond to participants or extend or cede maintainership.

I guess frustration speaks here? There is simply no responsibility an OSS maintainer has. They can choose to be responsible, but no one can force them. Eventually OSS licensing is THE solution at heart to solve this problem. Maintainers go rogue? Fork and move on. But surprise, who is going to fork AND maintain? Filling in all the demands from the community, for potentially no benefit? No one can force him to take th…

[deleted]

Re: Why I forked httpx

#100

Post by cachius »

Yokohiii wrote: post #65
cachius wrote: post #53

Earlier quoted context omitted.

This is not merely open-source, but taking part in a huge package ecosystem in a foundational role in an XKCD 2347 type of way for HTTP requests. Put your side project on your personal homepage and walk away - fine. Make it central infrastructure - respond to participants or extend or cede maintainership.

I guess frustration speaks here? There is simply no responsibility an OSS maintainer has. They can choose to be responsible, but no one can force them. Eventually OSS licensing is THE solution at heart to solve this problem. Maintainers go rogue? Fork and move on. But surprise, who is going to fork AND maintain? Filling in all the demands from the community, for potentially no benefit? No one can force him to take th…

Right, frustration about the no strings attached sentiment for OSS devs. Of course you've no obligations for support or maintenance, but with increasing exposure responsibility grows as de facto ever more projects, people, softwares depend on you.

This doesn't come over night and this is a spectrum and a choice. From purely personal side project over exotic Debian package to friggin httpx with 15k Github stars and 100 million downloads a week the 46th most downloaded PyPI package!

If this shall work reasonably in any way, hou have to step up. Take money (as they do, https://github.com/sponsors/encode), search fellow maintainers or cede involvement - even if only temporarily.

An example of a recent, successful transition is UniGetUI https://github.com/Devolutions/UniGetUI/discussions/4444

I feel there should be support from the ecosystem to help with that. OpenJS Foundation seems doing great: https://openjsf.org/projects. The Python Software Foundation could not only host PyPI but offer assistance for the most important packages.

Post reply on HN