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 => {
        body += data;
      });
      res.on('end', () => {
        resolve(body);
      });
    });
    req.end();
  });

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.

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

I've noticed that many languages struggle with HTTP in the standard library, even if the rest of the stdlib is great. I think it's just difficult to strike the right balance between "easy to use" and "covers every use case", with most erring (justifiably) toward the latter.

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.

> 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 _worse_ than urllib IMO), Rust , Java (UrlRequest is the same as python's), even dotnet's HttpClient is... fine.

Honestly the thing that consistently surprises me is that requests hasn't been standardised and brought into the standard library

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.

Bram's Law: https://files.catbox.moe/qi5ha9.png

Python makes everything so easy.

The HTTP protocol is easy to implement the basic features but hard to implement a full version that is also efficient.

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.

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.

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

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.)

Is it knee-quests or nigh-quests?

I've started seeing these emoji-prefixed commits lately now too, peculiar

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

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 project to suddenly break in a bad way without valid reason.

Without being perfect, I would advise everyone to switch to Aiohttp.

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.

>thread to call out Read the Docs for profiting from MkDocs without contributing back.

>They also point out that not opening up the source code goes against the principles of Open Source software development

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.

On one hand, that account of the attempted project takeover smelled to me like Jia Tan.

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.

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.

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?

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.

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.

It's gone from 45 when I looked at it an hour ago to 261 just now.

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 probably 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.

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.

thanks, I hope I fixed the https://pythonleiden.nl website now

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.

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.

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.

Yeah, it's a shame because otherwise the library is really nice and could have become the default HTTP library, but it feels like someone will manage to inject some weird behaviour soon and half the planet will be compromised