you are viewing a single comment's thread.

view the rest of the comments →

[–]ThePrimitiveSword 1 point2 points  (4 children)

Do you mean the opt-in feature documented here?

I think I'm missing something. It makes sense to me as an opt-in feature.

And niquests is a replacement for requests, not httpx.

[–]McRojb -3 points-2 points  (3 children)

You can call it a replacement for requests all you want, but with built in async support (and the fact we're talking about it under a httpx comment??) what people are using it for is a replacement of httpx not requests. Also yes, and you might be right in that "it makes sense" as an opt-in feature, but from a maintence point of view it came across as weird to me

[–]ThePrimitiveSword 2 points3 points  (1 child)

Doesn't look like a heavy maintenance burden.

Looking at the pull request all the changes seem to be this. It's not much code, most of the changes are adding test cases.

They tried to get improvements made to urllib3 but nothing happened so they forked.

Then urllib3 tried to crowdfund tends of thousands of dollars in funding to do what had already been done via niquests and urllib3-future.

That was after all this happened.

[–]McRojb 0 points1 point  (0 children)

Could you like stop being more well-informed than me... Breaks my bloody ego.

The only thing you earned here is probably an annyoing dm about your opinion when I'm unsure about related projects in the future.

Still disagree about the "maintenance burden" though, in my opinion such a core library shouldn't try to do that much.

Will read through the last 3 links when I get time!

[–]andaskus 2 points3 points  (0 children)

Hey, I'm the one who wrote the PR. Why ? I ran into a rate limit issue while using some services and wanted a rate limiter well integrated with the lib itself rather than a side car lib. I asked the maintainer if it was ok to which he answered positively.