| ▲ | mesahm 7 hours ago |
| 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. |
|
| ▲ | u_sama 7 hours ago | parent | next [-] |
| It is indeed a shame that niquests isn't used more, I think trying to use the (c'est Français) argument to in French will bring you many initial users needed for the inertia |
| |
| ▲ | mesahm 7 hours ago | parent [-] | | ahah, "en effet"! je m'en souviendrai. more seriously, all that is needed is our collective effort. I've done my part by scarifying a lot of personal time for it. | | |
| ▲ | u_sama 5 hours ago | parent [-] | | I saw there are almost no bugs or things to contribute, are there other ways to help ? | | |
| ▲ | mesahm 3 hours ago | parent [-] | | yes, plenty! testing it extensively, finding edge bugs, (...) and of course: spread the word on other project to help increasing adoption. |
|
|
|
|
| ▲ | samset7 3 hours ago | parent | prev | next [-] |
| We have switched to niquests in my company and yes I can confirm that it's 10x better than httpx :) |
| |
| ▲ | PyWoody an hour ago | parent | next [-] | | Did you have any warts when switching? httpx has been "fine" for me but this thread has me seriously considering changing to niquests. | |
| ▲ | mesahm 3 hours ago | parent | prev [-] | | nice to hear :) |
|
|
| ▲ | mananaysiempre 4 hours ago | parent | prev | next [-] |
| No Trio support yet, right? That’s the main reason to use httpx for me at least, and has been since I first typed “import httpx” some years ago. (Also the sponsorship subscription thing in the readme gives me vague rugpull vibes. Maybe I’ve just been burned too much—I don’t mean to discourage selling support in general.) |
| |
| ▲ | mesahm 3 hours ago | parent [-] | | help for getting it working is appreciated, we have it in mind.
duly noted about the sponsorship, we accept constructive criticism, and alternative can be considered. |
|
|
| ▲ | duskdozer 7 hours ago | parent | prev | next [-] |
| Is it knee-quests or nigh-quests? I've started seeing these emoji-prefixed commits lately now too, peculiar |
| |
| ▲ | mesahm 7 hours ago | parent | next [-] | | it's the gitmoji thing, I really don't like it, it was a mistake. Thinking to stop it soon. I was inspired by fastapi in the early days. I prefer conventionalcommits.org | | |
| ▲ | croemer 6 hours ago | parent [-] | | Please don't be too much inspired by FastAPI - at least regarding maintainer bus factor and documentation (FastAPI docs are essentially tutorial only), and requiring dozens of hoops to jump through to even open an issue. | | |
| ▲ | mesahm 6 hours ago | parent [-] | | agreed. as I said, it was a mistake from my end. and clearly looking to better myself. |
|
| |
| ▲ | u_sama 7 hours ago | parent | prev | next [-] | | There is a series of extensions for Vscode that add this functionality like https://github.com/ugi-dev/better-commits | | |
| ▲ | duskdozer 6 hours ago | parent [-] | | ah ok, I am familiar with and not exactly against (non-emoji) commit message prefixes | | |
| ▲ | rob an hour ago | parent [-] | | I better start seeing some caterpillar emojis in your next commits or we're gonna have a real problem! |
|
| |
| ▲ | mesahm 7 hours ago | parent | prev [-] | | nee-quests, I am French native. | | |
|
|
| ▲ | greatgib 7 hours ago | parent | prev | next [-] |
| 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 project to suddenly break in a bad way without valid reason. Without being perfect, I would advise everyone to switch to Aiohttp. |
| |
| ▲ | sgt 3 hours ago | parent | next [-] | | 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. | | |
| ▲ | nyrikki 35 minutes ago | parent [-] | | 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. |
| |
| ▲ | sammy2255 7 hours ago | parent | prev | next [-] | | aiohttp is for asynchronous contexts only | |
| ▲ | mesahm 7 hours ago | parent | prev [-] | | aiohttp is an excellent library. very stable. I concurs, but!
it's too heavily tied to HTTP/1, and well, I am not a fan of opening thousands of TCP conn just to keep up with HTTP/2 onward. niquests easily beat aiohttp just using 10 conn and crush httpx see https://gist.github.com/Ousret/9e99b07e66eec48ccea5811775ec1... fwiw, HTTP/2 is twelve years old, just saying. |
|
|
| ▲ | roywashere 5 hours ago | parent | prev | next [-] |
| Thanks, I'll link to your project |
| |
|
| ▲ | Orelus 7 hours ago | parent | prev | next [-] |
| Can confirm, more features, a breeze to switch. |
|
| ▲ | hrmtst93837 5 hours ago | parent | prev [-] |
| Half-melded side projects just pollute PyPI more, you get less grief long-term by biting the bullet and shipping a fork that owns its tradeoffs. |
