Hacker Newsnew | past | comments | ask | show | jobs | submit | mmmaantu's commentslogin

Building pyreqwest, a high-performance Python HTTP client backed by Rust’s reqwest. It has gotten quite feature rich: async and sync APIs, similar ergonomic interface of reqwest, full type hints, and built-in testing/mocking. It has no unsafe code, and no Python-side dependencies. (Started after getting too annoyed with all the issues httpx has.)

https://github.com/MarkusSintonen/pyreqwest


I've recently updated an internal tool which basically acts as a configuration and dependency/context manager for performing hundreds of api calls. I added an httpx backend (to test vs the current urllib3 backend) and also introduced an async API (httpx as well). However, from your benchmarks it seems like I should've went with aiohttp for faster async? I will work on integrating pyreqwest as well


Yes httpx is badly broken. Eg its connection pooling implementation is not great at all. There are various issues in httpx/httpcore. There are also old open PRs trying to fix issues but maintainer(s) are just not intrested.


Good to know, will be interesting when we run our tests. Thanks for the info and for your work on pyreqwest, looks very promising


That sounds awesome. But I have two curiosities: What are the problems of httpx? And was pycurl not enough for what you wanted to do?


Httpx/httpcore are abandoned and their connection pooling etc implementations are completely broken https://github.com/encode/httpx/issues/3215 Many PRs trying to fix varying issues https://github.com/encode/httpcore/pulls But maintainer(s) are not intrested in fixing any of the issues.


pycurl doesnt support async, right?


I have been working on a new Python HTTP client which is 100% Rust-based (sync+async). Using reqwest under the hood and providing everything it has to offer to Python land + much more. Also including mocking capabilities. Here: https://github.com/MarkusSintonen/pyreqwest

Started from the poor state of many Python HTTP clients and poor testing utilities there is for them. (Eg the neglected state of httpx and its all perf issues)


Oh Hi! Very cool. Looks very similar to my project's reqwest wrapper. maybe we should team up!?

https://github.com/jessekrubin/ry

https://github.com/jessekrubin/ry/tree/main/crates/ryo3-reqw...


SHA pinning won't necessarily help if the dependency you are pinning doesn't pin its own dependencies! You still get stuff pulled via vulnerable tags etc. How long till we get this https://github.com/github/roadmap/issues/592 ...


Yes, this is a crucial distinction to make. The fact of the matter is that you have to treat GitHub Actions like a compromised system. Sure, there's not a ton of steps you can take for protecting builds if it's your primary builder, but you can for example not hook up an AWS account with full admin privileges to it (which I've seen more times than I would have like to).


https://github.com/features/preview/immutable-actions

They are actually releasing this very soon. I’ve seen some of my workflows use an immutable OCI image for some of GH’s actions like actions/checkout.


Isn't that wrong? I think you have to pre-bundle your actions, it won't do an npm install.


I set up this recently at a new company and did yarn + ncc to build a compiled js out of typescript. It was a bit hairy as a novice, but ended up working fine.

That protects from npm supply chain stuff, but obviously third-party includes like docker/build-push-action are still a risk.


Thanks for highlighting this open issue.

The fact they've been stalling this for a good 2.5 years is... insane??


I don't believe that's true. If you pin to a hash, then it will always run that version and can't change


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: