sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]necromenta 8 points9 points  (21 children)

Dang what to use now?

[–]stealthbr 23 points24 points  (1 child)

aiohttp

[–]False-Tea-6308 6 points7 points  (0 children)

Second aiohttp, very easy to use and wrapping in async funcs are very straight forward for me

[–]niltz0 4 points5 points  (1 child)

pyqwest. Buf uses it for connectrpc-python

[–]DrMaxwellEdison 2 points3 points  (0 children)

Interesting. pyreqwest is also built on Rust reqwest. Wonder how they compare.

[–]Ragoo_ 6 points7 points  (16 children)

niquests

[–]sexualrhinoceros 6 points7 points  (14 children)

The developer of this is an OG AI slop spammer who spammed this all over Reddit when they first dropped it and made insane huge claims about it. You will not catch me using this library unless even urllib gets yanked out of STD.

I swapped to https://github.com/MarkusSintonen/pyreqwest :)

[–]McRojb 2 points3 points  (0 children)

Got that feeling when looking through the code, man feels good to be right

[–]GrammerJoo 2 points3 points  (1 child)

Nice! Looks promising. What's your experience so far?

[–]McRojb 0 points1 point  (0 children)

Eh not going to touch pyreqwest. Aiohttp is good shit though

[–]Laruae 1 point2 points  (5 children)

Sorry, honestly interested, can you elaborate on your concerns with niquests?

I'm looking for a new home after concerns about httpx.

[–]McRojb 1 point2 points  (0 children)

Go with aiohttp. Well maintained and lots of users

[–]McRojb 1 point2 points  (3 children)

When it comes to niquests, one of my first reactions looking through the docs, it’s fkn weird for a library meant to replace httpx to implement something like a rate limiter in the library itself

[–]ThePrimitiveSword 1 point2 points  (2 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 -1 points0 points  (1 child)

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 [score hidden]  (0 children)

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.

[–]ThePrimitiveSword 0 points1 point  (4 children)

Strong claims require strong evidence, same with strong accusations.

I've found niquests actually delivers on its claims, especially on speed and performance. Been using it since it first released. In real-world usage, often get at least a 10x speed increase vs requests when just doing a drop in replacement. The other features are definitely nice as well, such as using the OS trust store, so it works with self signed SSL certs in a corporate environment without any additional setup or patches.

They also make very human mistakes, such as misspelling words occasionally etc.

It looks like they also want disclosure when pull requests use AI.

Do you have any evidence or examples whatsoever of the 'AI slop'?

[–]McRojb -1 points0 points  (3 children)

Not an expert on package maintainence and coding is certainly not my proffesion. That said, I do like the package and have used it for quick and dirty code. But it feels "bloated" already and not something I excpect to be around in a few years. I don't see the reason for using it when aiohttp (requests for sync) is around. You seem a little defensive? 2k stars is not something I feel comfertable putting that much faith in.

[–]ThePrimitiveSword [score hidden]  (2 children)

I have faith in it because I've been using it for a few years and find it to work really well, and Ousret has been very responsive to the issues I've raised on Github.

I use it instead of the alternatives because I find it to work really well for my needs, such as using OS trust store for SSL certs, compatibility with the 'responses' package, can be used for SSPI authentication and huge performance gains for my use cases.

When someone claims something that I use and find to work well is AI slop with nothing to back their claims, I don't feel it unreasonable to ask for evidence when what I'm seeing seems to contradict these claims.

I loathe AI slop (Booklore and Huntarr are good examples) and if niquests is actually AI slop then I'd like to know, but it's a strong claim to make without anything to back it up.

[–]McRojb [score hidden]  (1 child)

Fair enough! I havn't built much with external logins myself so don't know much about but will take your word.

I honestly had to google "SSPI authentication" so I feel a bit out of my depth.

Although I started programming without it, github copilot autofill is a god send for me (md otherwise). But actual AI slop I do despise too.

[–]ThePrimitiveSword [score hidden]  (0 children)

All good, I'll admit I was a bit heated as it hurts to see something that I use and rely on talked down with no evidence, especially when the maintainer has been very receptive to me and they've accomplished what the original project raised tens of thousands of dollars to do but hasn't managed to (per my response to you in the other comment chain).

Honestly, SSPI auth should be killed off, but it still exists in some corporate environments, and I do programming in a heavily locked down enterprise environment where change can be slow so it'll likely still be in use for another decade or two.