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

51–60 of 194 posts

Re: Why I forked httpx

#51

Post by Spivak »

localuser13 wrote: post #34
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…

>Honestly the thing that consistently surprises me is that requests hasn't been standardised and brought into the standard library Instead, official documentation seems comfortable with recommending a third party package: https://docs.python.org/3/library/urllib.request.html#module... >The Requests package is recommended for a higher-level HTTP client interface. Which was fine when requests were the de-facto-standard…

Well, the reason for all the fragmentation is because the Python stdlib doesn't have the core building blocks for an async http or http2 client in the way requests could build on urllib.

The h11, h2, httpcore stack is probably the closest thing to what the Python stdlib should look like to end the fragmentation but it would be a huge undertaking for the core devs.

Re: Why I forked httpx

#52

Post by [deleted] »

rglullis wrote: post #27
znpy wrote: post #16

Earlier quoted context omitted.

Oh i recognised one of the involved people immediately, drama person. I still think that hijacking the mkdocs package was the wrong way to go though. The foss landscape has become way too much fork-phobic. Just fork mkdocs and go over your merry way.

Drama around Starlette. Drama around httpx. Drama around MkDocs. I just hope that DRF is not next, I still have some projects that depend on it.

[deleted]

Re: Why I forked httpx

#53

Post by cachius »

nathell wrote: post #17

Congratulations on forking! Always remember that open-source is an author’s gift to the world, and the author doesn’t owe anything to anyone. Thus, if you need a feature that for whatever reason can’t or won’t go upstream, forking is just about the only viable option. Fingers crossed!

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.

Re: Why I forked httpx

#55

Post by Spivak »

Do you see yourself taking over httpcore as well as it's likely to have the same maintainership problem? It would certainly instill more confidence that this is a serious fork.

This certainly wouldn't be the first time an author of a popular library got a little too distracted on the sequel to their library that the current users are left to languish a bit.

Re: Why I forked httpx

#57

Post by ivanjermakov »

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)

HTTP client is at the intersection of "necessary software building block" and "RFC 2616 intricacies that are hard to implement". Has nothing to do with Python really.

Re: Why I forked httpx

#58

Post by umvi »

maccard wrote: post #29
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)

> 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…

What's wrong with Go's? I've never had any issues with it. Go has some of the best http batteries included of any language

Re: Why I forked httpx

#59

Post by wging »

dirkc wrote: post #49
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)

You would think that sending HTTP requests is a basic capability, but I've had fun in many languages doing so. Long ago (2020, or not so long ago, depending on how you look at it) I was surprised that doing an HTTP request on node using no dependencies was a little awkward: const response = await new Promise( (resolve, reject) => { const req = https.request(url, { }, res => { let body = ""; res.on("data", data => { b…

These days node supports the fetch API, which is much simpler. (It wasn't there in 2020, it seems to have been added around 2022-2023.)
Post reply on HN