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:<p><pre><code> const response = await new Promise( (resolve, reject) => {
const req = https.request(url, {
}, res => {
let body = "";
res.on("data", data => {
body += data;
});
res.on('end', () => {
resolve(body);
});
});
req.end();
});</code></pre>
Web standards have rich support for incremental/chunked payloads, the original node APIs are designed around it. From this lens the Node APIs make sense.
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.)
Yes, thankfully! It's amusing to read what they say about fetch on nodejs.org [1]:<p>> Undici is an HTTP client library that powers the fetch API in Node.js. It was written from scratch and does not rely on the built-in HTTP client in Node.js. It includes a number of features that make it a good choice for high-performance applications.<p>[1] - <a href="https://nodejs.org/en/learn/getting-started/fetch" rel="nofollow">https://nodejs.org/en/learn/getting-started/fetch</a>
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.
Bram's Law: <a href="https://files.catbox.moe/qi5ha9.png" rel="nofollow">https://files.catbox.moe/qi5ha9.png</a><p>Python makes everything so easy.
Don't think it's Python-specific, it's humanity-specific and Python happens to be popular so it happens more often/ more publicly in Python packages.
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.
> Then I found out it was broken. I contributed a fix. The fix was ignored and there was never any release since November 2024.<p>This seems like a pretty good reason to fork to me.<p>> 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,<p>Or Javascript (well node), or golang (http/net is _worse_ than urllib IMO), Rust , Java (UrlRequest is the same as python's), even dotnet's HttpClient is... fine.<p>Honestly the thing that consistently surprises me is that requests hasn't been standardised and brought into the standard library
What, Go's net/http is fantastic. I don't understand that take. Many servers are built on it because it's so fully featured out of the box.
Your java knowledge is outdated. Java's JDK has a nice, modern HTTP Client <a href="https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html" rel="nofollow">https://docs.oracle.com/en/java/javase/11/docs/api/java.net....</a>
Ahh, java. You never change, even if you're modern<p><pre><code> HttpClient client = HttpClient.newBuilder()
.version(Version.HTTP_1_1)
.followRedirects(Redirect.NORMAL)
.connectTimeout(Duration.ofSeconds(20))
.proxy(ProxySelector.of(
new InetSocketAddress("proxy.example.com", 80)
))
.authenticator(Authenticator.getDefault())
.build();
HttpResponse<String> response = client.send(request, BodyHandlers.ofString());
System.out.println(response.statusCode());
System.out.println(response.body());
</code></pre>
For the record, you're most likely not even interacting with that API directly if you're using any current framework, because most just provide automagically generated clients and you only define the interface with some annotations
Your http client setup is over-complicated. You certainly don't need `.proxy` if you are not using a proxy or if you are using the system default proxy, nor do you need `.authenticator` if you are not doing HTTP authentication. Nor do you need `version` since there is already a fallback to HTTP/1.1.<p><pre><code> HttpClient client = HttpClient.newBuilder()
.followRedirects(Redirect.NORMAL)
.connectTimeout(Duration.ofSeconds(20))
.build();</code></pre>
What's the matter with this? It's a clean builder pattern, the response is returned directly from send. I've certainly seen uglier Java
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
>Honestly the thing that consistently surprises me is that requests hasn't been standardised and brought into the standard library<p>Instead, official documentation seems comfortable with recommending a third party package: <a href="https://docs.python.org/3/library/urllib.request.html#module-urllib.request" rel="nofollow">https://docs.python.org/3/library/urllib.request.html#module...</a><p>>The Requests package is recommended for a higher-level HTTP client interface.<p>Which was fine when requests were the de-facto-standard only player in town, but at some point modern problems (async, http2) required modern solutions (httpx) and thus ecosystem fragmentation began.
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.<p>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.
Node now supports the Fetch API.
> dotnet's HttpClient is... fine.<p>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 ).<p>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.<p>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.<p>[1] <a href="https://learn.microsoft.com/en-us/dotnet/core/extensions/httpclient-factory" rel="nofollow">https://learn.microsoft.com/en-us/dotnet/core/extensions/htt...</a>
requests is some janky layer onto of other janky layers. last thing you want in the stdlib.<p>it's called the STD lib for a reason...
The HTTP protocol is easy to implement the basic features but hard to implement a full version that is also efficient.<p>I've often ended up reimplementing what I need because the API from the famous libraries aren't efficient. In general I'd love to send a million of requests all in the same packet and get the replies. No need to wait for the first reply to send the 2nd request and so on. They can all be on the same TCP packet but I have never met a library that lets me do that.<p>So for example while http3 should be more efficient and faster, since no library I've tried let me do this, I ended up using HTTP1.1 as usual and being faster as a result.
This sounds like an ideal use case for modshim [0]<p>One of its intended use cases is bridging contribution gaps: while contributing upstream is ideal, maintainers may be slow to merge contributions for various reasons. Forking in response creates a permanent schism and a significant maintenance burden for what might be a small change. Modshim would allow you to create a new Python package containing only the fixes for your bugbears, while automatically inheriting the rest from upstream httpx.<p>[0] <a href="https://github.com/joouha/modshim" rel="nofollow">https://github.com/joouha/modshim</a>
Since modshim isn't money patching and appears to only be wrapping the external API of a package, if the change is deep enough inside the package, wouldn't you end up reimplementing most of the package from the outside?
the http landscape is rather scary lately in Python. instead of forking join forces... See Niquests <a href="https://github.com/jawah/niquests" rel="nofollow">https://github.com/jawah/niquests</a><p>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.<p>(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.
It is indeed a shame that niquests isn't used more, I think trying to use the (c'est Français) argument to in French will bring you many initial users needed for the inertia
We have switched to niquests in my company and yes I can confirm that it's 10x better than httpx :)
Is it knee-quests or nigh-quests?<p>I've started seeing these emoji-prefixed commits lately now too, peculiar
it's the gitmoji thing, I really don't like it, it was a mistake. Thinking to stop it soon. I was inspired by fastapi in the early days. I prefer conventionalcommits.org
There is a series of extensions for Vscode that add this functionality like <a href="https://github.com/ugi-dev/better-commits" rel="nofollow">https://github.com/ugi-dev/better-commits</a>
nee-quests, I am French native.
niquests as in "niquer" ?<p>J'aime bien, j'aime bien
I guess kind of obvious now noticing the rhyme
The basis of httpx is not very good at all.<p>I think that it owes its success to be first "port" of python requests to support async, that was a strong need.<p>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 project to suddenly break in a bad way without valid reason.<p>Without being perfect, I would advise everyone to switch to Aiohttp.
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.
aiohttp is an excellent library. very stable. I concurs, but!
it's too heavily tied to HTTP/1, and well, I am not a fan of opening thousands of TCP conn just to keep up with HTTP/2 onward. niquests easily beat aiohttp just using 10 conn and crush httpx see <a href="https://gist.github.com/Ousret/9e99b07e66eec48ccea5811775ec116d" rel="nofollow">https://gist.github.com/Ousret/9e99b07e66eec48ccea5811775ec1...</a><p>fwiw, HTTP/2 is twelve years old, just saying.
aiohttp is for asynchronous contexts only
Thanks, I'll link to your project
Can confirm, more features, a breeze to switch.
Half-melded side projects just pollute PyPI more, you get less grief long-term by biting the bullet and shipping a fork that owns its tradeoffs.
More related drama: The Slow Collapse of MkDocs (<a href="https://fpgmaas.com/blog/collapse-of-mkdocs/" rel="nofollow">https://fpgmaas.com/blog/collapse-of-mkdocs/</a>)
>thread to call out Read the Docs for profiting from MkDocs without contributing back.<p>>They also point out that not opening up the source code goes against the principles of Open Source software development<p>I will never stop being amused when people have feelings like this and also choose licenses like BSD (this project). If you wanted a culture that discouraged those behaviors, why would you choose a license that explicitly allows them? Whether you can enforce it or not, the license is basically a type of CoC that states the type of community you want to have.
The reason is simple: they'd like to reap all the benefits of a permissive licence (many people and companies won't or can't touch GPL code), without any of the downsides; but these downsides are the very reason behind the rules in more 'restrictive' licenses like the GPL.<p>This usually doesn't work, and in the end all they can do is complain about behaviours that their license choice explicitly allowed.
Yes I agree completely. I am baffled why they choose that license in the first place. It just seems to engender drama when people actually follow the license they've chosen! Perhaps open source is actually powered by drama, where developers have more meaning from the drama they create than the actual things they create?
On one hand, that account of the attempted project takeover smelled to me like Jia Tan.<p>On the other hand, the comments the MkDocs author is making about perceived gender grievances feel so unhinged that I wouldn't be touching anything made by them with a barge pole.
If this would be a tv show I probably would view it, but wow what a drama.
Oh i recognised one of the involved people immediately, drama person.<p>I still think that hijacking the mkdocs package was the wrong way to go though.<p>The foss landscape has become way too much fork-phobic.<p>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.
Per TFA, there’s similarly-shaped low-key drama around DRF too[1] although issues and discussions have been reënabled since then.<p>[1] <a href="https://github.com/orgs/encode/discussions/11#discussioncomment-12311196" rel="nofollow">https://github.com/orgs/encode/discussions/11#discussioncomm...</a>
What's the drama around starlette? (Can't find anything)
[dead]
Right, my suspicion was correct. When I interacted with them a few years ago they seemed perfectly nice and friendly, but seem to have gone off the rails more recently. It's an uncomfortable situation and I've a feeling people are afraid to discuss this kind of thing but we really need to. People are a risk factor in software projects and we need to be resilient to changes they face. Forking is the right way, but places like GitHub have sold people on centralisation. We need to get back to decentralised dev.
> but places like GitHub have sold people on centralisation. We need to get back to decentralised dev.<p>I don’t think that’s the case. It’s more of a marketing/market incentive. It’s great pr to be associated with the most famous project, way less so to be associated with a fork, at least until the fork becomes widespread and well recognised.<p>GitHub does make it fairly easy to fork a project, I wouldn’t blame the situation on github.
Somehow I confused httpx with htmlx
I guess you mean htmx. Same here. I read the article for a while, and was confused by "HTTPX is a very popular HTTP client for Python." and wondering "why is OpenAI using htmx", until I eventually realized what's going on.
And also htmlx with htmx I guess?
I've been reading the whole article wrong too.
Same! Only just realized it thanks to your comment.
I guess the Discussion on Hacker News href should be "<a href="https://news.ycombinator.com/item?id=47514603">https://news.ycombinator.com/item?id=47514603</a>" instead of "news.ycombinator.com/item?id=47514603"
Congratulations on forking!<p>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.<p>Put your side project on your personal homepage and walk away - fine.<p>Make it central infrastructure - respond to participants or extend or cede maintainership.
If "taking part in a huge ecosystem in a foundational role" means 'other people choosing to use your FOSS software', and I can't think of what else it would mean, then no, you have no obligation to do any of that.<p>FOSS means the right to use and fork. That's all it means. That's all it ever meant. Any social expectations beyond that live entirely in your imagination.
I guess frustration speaks here?<p>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?<p>No one can force him to take the responsibility, just like no one can force anyone else to.
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.<p>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!<p>If this shall work reasonably in any way, hou have to step up. Take money (as they do, <a href="https://github.com/sponsors/encode" rel="nofollow">https://github.com/sponsors/encode</a>), search fellow maintainers or cede involvement - even if only temporarily.<p>An example of a recent, successful transition is UniGetUI <a href="https://github.com/Devolutions/UniGetUI/discussions/4444" rel="nofollow">https://github.com/Devolutions/UniGetUI/discussions/4444</a><p>I feel there should be support from the ecosystem to help with that. OpenJS Foundation seems doing great: <a href="https://openjsf.org/projects" rel="nofollow">https://openjsf.org/projects</a>. The Python Software Foundation could not only host PyPI but offer assistance for the most important packages.
>> 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.<p>This is an oxymoron. Either you have obligations, or you don't. There's no such thing as having "no obligations" but also "growing responsibility".<p>I don't understand how you can possibly conclude that just because you've chosen to become dependent on some FOSS library, they owe you anything. You don't get to somehow impose obligations on other people by your choices. They get none of your profits, but they're somehow responsible to you for your business risks? Nonsense.<p>It is a condition of your use of the code that you've accepted its license, and FOSS licenses are CRYSTAL CLEAR (ALL CAPS) on what obligations or responsibilities the authors have towards you - none whatsoever. Your use of the software is contingent on your acceptance of that license.<p>If that lack of warranty poses an unacceptable business risk to you, <i>go buy support</i>. Pay a dev to fix the issues you're having, rather than inventing some fictitious responsibility they have to you to do it for free.
A foundational role in a huge open-source package ecosystem? I wonder what such an esteemed position pays.
> Visitor 4209 since we started counting<p>Loved that little detail, reminds me of the old interwebs :)
I'm not a lawyer, but are there any potential trademark issues? AFAIK in general you HAVE to change the name to something clearly different. I consider it morally OK, and it's probably fine, but HTTPXYZ is cutting it close. It's too late for a rebrand, but IMO open-source people often ignore this topic a bit too much.
Don't you need to register and actively defend you trademark for it to apply?
I don't think HTTPX is a registered trademark.
Is httpx trademarked? I couldn't find anything indicating it was.
He would <i>probably</i> win in a legal case, but is he actually going to take it to court? I doubt it. Also I wouldn't be too offended about the name if I were him and for users it's better because it makes the link clearer.<p>I think if had named it HTTPX2 or HTTPY, that would be much worse because it asserts superiority without earning it. But he didn't.
Good line from the blog post ...<p>"So what is the plan now?" - "Move a little faster and not break things"
The lack of a well-maintained async HTTP client in Python's stdlib has been a pain point for a while. Makes sense someone eventually took it into their own hands
Another abandoned project hurting users: <a href="https://github.com/benweet/stackedit" rel="nofollow">https://github.com/benweet/stackedit</a>
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.<p>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.
Hi Michiel!<p>Just a small headsup: clicking on the Leiden Python link in your About Me page give not the expected results.<p>And a small nitpick: it's "Michiel's" in English (where it's "Michiels" in Dutch).<p>Thanks for devoting time to opensource... <3
It's a shame, httpx has so much potential to be the default Python http library. It's crazy that there isn't one really. I contributed some patches to the project some years ago now and it was a nice and friendly process. I was expecting a v1 release imminently. It looks like the author is having some issues which seem to afflict so many in this field for some reason. I notice they've changed their name since I last interacted with the project...
You try to touch low level HTTP with Python, and once you dive into both RFC2616 and Python deep enough, your brain is cooked, basically. Look at what happened to the author of requests, a textbook example.<p>Or maybe it is that your brain is cooked already, or is on the brink, and your condition attracts you to HTTP and Python, after which it basically has you.<p>The only way to not go bonkers is to design a library by commitee, so that the disease spreads evenly and doesn't hit any one individual with full force. The result will be ugly, but hopefully free of drama.
[dead]
[dead]
[dead]
[dead]
[dead]
smells like supply chain attack