Live data from Hacker News

Why I forked httpx

tildeweb.nl

141–150 of 194 posts

Re: Why I forked httpx

#141

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)

httpx has async support (much like aiohttp), whereas urllib is blocking-only. If you need to make N concurrent requests, urllib requires N threads or processes.

Re: Why I forked httpx

#142
post #93

Earlier quoted context omitted.

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.

I started using the ports and adapters pattern and protocol for any packages that have replacements or concerns.

Basically treating HTTP requests as an orthogonal, or cross-cutting concern.

It is sometimes hard to tell if these upstream packages are stable or abandoned.

I should probably document my methodology so it can help others or at least have the chance to find out what mistakes or limitations they might have.

Re: Why I forked httpx

#143

Earlier quoted context omitted.

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

Yeah this is all over Rust codebases too for good reason. The argument is that default params obfuscate behaviour and passing in a struct (in Rust) with defaults kneecaps your ability to validate parameters at compile time.

It does have defaults, the above example manually sets everything to show people reading the docs what that looks like.

Re: Why I forked httpx

#144

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)

Bram's Law: https://files.catbox.moe/qi5ha9.png Python makes everything so easy.

converted to text:

I realized this the other day, and dub it Bram's Law -- Bram

Bram's Law

The easier a piece of software is to write, the worse it's implemented in practice. Why? Easy software projects can be done by almost any random person, so they are. It's possible to try to nudge your way into being the standard for an easy thing based on technical merit, but that's rather like trying to become a hollywood star based on talent and hard work. You're much better off trading it all in for a good dose of luck.

This is why HTTP is a mess while transaction engines are rock solid. Almost any programmer can do a mediocre but workable job of extending HTTP, (and boy, have they,) but most people can't write a transaction engine which even functions. The result is that very few transaction engines are written, almost all of them by very good programmers, and the few which aren't up to par tend to be really bad and hardly get used. HTTP, on the other hand, has all kinds of random people hacking on it, as a result of which Python has a 'fully http 1.1 compliant http library which raises assertion failures during normal operation.

Remember this next time you're cursing some ubiquitous but awful third party library and thinking of writing a replacement. With enough coal, even a large diamond is unlikely to be the first thing picked up. Save your efforts for more difficult problems where you can make a difference. The simple problems will continue to be dealt with incompetently. It sucks, but we'll waste a lot less time if we learn to accept this fact.

Re: Why I forked httpx

#145

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

An async HTTP client in the stdlib would also be great for tools like pip, which could really benefit from doing more async work. One of the reasons that uv is much faster is precisely this.

Re: Why I forked httpx

#146

Earlier quoted context omitted.

Don't you need to register and actively defend you trademark for it to apply?

There are unregistered trademarks as well as registered ones. Usually the "TM" symbol is applied to unregistered trademarks, and the ® symbol for registered ones. Both enjoy protection, although it's generally an easier time in court when your trademark is registered. Whether actively defending your trademark is actually required is a bit of a nuanced topic. Generally, trademarks can be lost through genericide (the m…

In this case, the name is already so generic that you might even be denied a trademark in the first place.

Re: Why I forked httpx

#147
post #123

Earlier quoted context omitted.

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.

> On one hand, that account of the attempted project takeover smelled to me like Jia Tan. Oleh was basically the sole maintainer for many years, and the development basically stopped when he left.

Yes, I know you can be legit, but when you first contribute a few useful things, then jump to maintainership and want keys to the kingdom, the pattern looks similar (sans the last step which is embedding some backdoor). At least in how the article described it.

Re: Why I forked httpx

#148

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)

Python doesn't have a big company behind it

Re: Why I forked httpx

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

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

Who are they?

Re: Why I forked httpx

#150

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)

AFAICT, lacking a (good) standard HTTP library is kind of the norm in popular languages. Python, Ruby, Rust, etc. all either have a lackluster standard one or are missing one. I think it sits between two many decision pressures for most languages: there are a _lot_ of different RFCs both required and implied, lots of different idioms you could pick for making requests, lots of different places to draw the line on wha…

Is Rust popular? It's popular among HN users, and among certain other bubbles, but can it be called generally popular? Ruby sure can't be.
Post reply on HN