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

151–160 of 194 posts

Re: Why I forked httpx

#151

Post by woodruffw »

Pay08 wrote: post #150
woodruffw wrote: post #140

Earlier quoted context omitted.

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.

It's popular enough to be worth using as a datapoint. What's the point of the question?

Re: Why I forked httpx

#152

Post by xnorswap »

pixl97 wrote: post #135
xnorswap wrote: post #91

Earlier quoted context omitted.

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…

>"It's been around for a while" is 14 years not a while?

It is, but it's also a decade after the language was first released.

Re: Why I forked httpx

#153

Post by LtWorf »

mesahm wrote: post #116
LtWorf wrote: post #72

Earlier quoted context omitted.

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

I spend 3 years developing Niquests, and believe me, HTTP is far from easy. Being a client means you have to speak to everyone, and no one have to speak to you (RFC are nice, but in practice never applied as-is). Once you go deep under the implementation, you'll find a thousand edge cases(...). And yes, the myth that as developer http/1 is "best" only means that the underlying scheduler is weak. today, via a dead sim…

I never said i was using asyncio

Re: Why I forked httpx

#154

Post by colejohnson66 »

pjmlp wrote: post #134
colejohnson66 wrote: post #117

Earlier quoted context omitted.

The boilerplate of not having sane defaults. .NET is much simpler: using HttpClient client = new(); HttpResponseMessage response = await client.GetAsync("https://..."); if (response.StatusCode is HttpStatusCode.OK) { string s = await response.Content.ReadAsStringAsync(); // ... }

Yeah, so much simpler, "Common IHttpClientFactory usage issues" https://learn.microsoft.com/en-us/dotnet/core/extensions/htt... "Guidelines for using HttpClient" https://learn.microsoft.com/en-us/dotnet/fundamentals/networ... And this doesn't account for all gotchas as per .NET version, than only us old timers remember to cross check.

I didn't mention IHttpClientFactory - just HttpClient. I will concede that ASP manages to be confusing quite often. As for the latter, guidelines are not requirements anymore than "RTFM" is; You can use HttpClient without reading the guidelines and be just fine.

Re: Why I forked httpx

#155

Post by yoyohello13 »

denimnerd42 wrote: post #139
yoyohello13 wrote: post #136

Earlier quoted context omitted.

Most Python developers these days weren't even programming when the 2 -> 3 split happened. Unless you're referencing something else.

the batteries included approach is the stdlib that can do everything. turns out it’s hard to maintain and make good.

Yeah that's true. Go seems to be handling the 'fat stdlib' approach pretty well though. I really don't want Python to got the path of Rust where nothing is included.

Re: Why I forked httpx

#156

Post by pjmlp »

colejohnson66 wrote: post #154
pjmlp wrote: post #134

Earlier quoted context omitted.

Yeah, so much simpler, "Common IHttpClientFactory usage issues" https://learn.microsoft.com/en-us/dotnet/core/extensions/htt... "Guidelines for using HttpClient" https://learn.microsoft.com/en-us/dotnet/fundamentals/networ... And this doesn't account for all gotchas as per .NET version, than only us old timers remember to cross check.

I didn't mention IHttpClientFactory - just HttpClient. I will concede that ASP manages to be confusing quite often. As for the latter, guidelines are not requirements anymore than "RTFM" is; You can use HttpClient without reading the guidelines and be just fine.

For various outcomes of fine, depending on .NET version, given that not everyone is on very latest.

Re: Why I forked httpx

#157

Post by freedomben »

looperhacks wrote: post #138
freedomben wrote: post #124

Earlier quoted context omitted.

Just my opinion of course, but: > What's the matter with this? To me what makes this very "Java" is the arguments being passed, and all the OOP stuff that isn't providing any benefit and isn't really modeling real-world-ish objects (which IMHO is where OOP shines). .version(Version.HTTP_1_1) and .followRedirects(Redirect.NORMAL) I can sort of accept, but it requires knowing what class and value to pass, which is look…

> but it requires knowing what class and value to pass Unless you use a text editor without any coding capabilities, your IDE should show you which values you can pass. The alternative is to have more methods, I guess? > why can't I just pass 20 or 20_000 or something 20 what? Milliseconds? Seconds? Minutes? While I wouldn't write the full Duration.ofSeconds(20) (you can save the "Duration."), I don't understand how…

Fair points.

> Unless you use a text editor without any coding capabilities, your IDE should show you which values you can pass. The alternative is to have more methods, I guess?

Fair enough, as much as I don't like it, in Java world it's safe to assume everyone is using an IDE. And when your language is (essentially) dependent on an IDE, this becomes a non-issue (actually I might argue it's even a nice feature since it's very type safe).

> 20 what? Milliseconds? Seconds? Minutes? While I wouldn't write the full Duration.ofSeconds(20) (you can save the "Duration."), I don't understand how one could prefer a version that makes you guess the unit.

I would assume milliseconds and would probably have it in the method name, like timeoutMs(...) or something. I will say it's very readable, but if I was writing it I'd find it annoying. But optimizing for readability is a reasonable decision, especially since 80% of coding is reading rather than writing (on average).

Re: Why I forked httpx

#158

Post by _boffin_ »

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

What issues do / did you have with HTTPx?

Re: Why I forked httpx

#159

Post by notatallshaw »

WhyNotHugo wrote: post #145
zeeshana07x wrote: post #38

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.

As a pip maintainer I don't think that's really true. The resolver in both pip and uv are fundamentally sequential and single threaded, you can't really queue up or split out jobs.

What uv does is parallelize the final download of packages after resolution, and batch pre-fetch metadata during resolution. I don't think these benefit from async, due to their batch nature classic multi-threaded download pools are probably the better solution, but I could be wrong!

Experiments have been done on the former in pip and didn't find much/any improvement in CPython, this may change in free threaded CPython. For the latter we currently don't have the information from the resolver to extract a range of possible metadata versions we could pre-range, I am working on this but it requires new APIs in packaging (the Python library) and changes to the resolver, and again we will need to benchmark to see if adding pre-fetching actually improves things.

Re: Why I forked httpx

#160

Post by ffsm8 »

Tostino wrote: post #120
ffsm8 wrote: post #111

Earlier quoted context omitted.

It was literally just copy pasted from the linked source (the official Oracle docs)

And those docs were likely trying to show you how to use multiple features, not the most basic implementation of it

I mean dont get me wrong, I work with Java basically 8 hours per day. I also get _why_ the API is as it is - It essentially boils down to the massive Inversion of Control fetish the Java ecosystem has.

It does enable code that "hides" implementation very well, like the quoted examples authentication API lets you authenticate in any way you can imagine, as in literally any way imaginable.

Its incredibly flexible. Want to only be able to send the request out after you've touched a file, send of a Message through a message broker and then maybe flex by waiting for the response of that async communication and use that as a custom attribute in the payload, additionally to a dynamically negotiated header to be set according to the response of a DNS query? yeah, we can do that! and the caller doesnt have to know any of that... at least as long as it works as intended

Same with the Proxy layer, the client is _entirely_ extensible, it is what Inversion of Control enables.

It just comes with the unfortunate side-effect of forcing the dev to be extremely fluent in enterprisey patterns. I dont mind it anymore, myself. the other day ive even implemented a custom "dependency injection" inspired system for data in a very dynamic application at my dayjob. I did that so the caller wont even need to know what data he needs! it just get automatically resolved through the abstraction. But i strongly suspect if a jr develeoper which hasnt gotten used to the java ecosystem will come across it, he'll be completely out of his depth how the grander system works - even though a dev thats used to it will likely understand the system within a couple of moments.

Like everything in software, everything has advantages and disadvantages. And Java has just historically always tried to "hide complexity", which in practice however paradoxically multiplies complexity _if youre not already used to the pattern used_.

Post reply on HN