Great! Sometimes you don't need huge magic libraries with tons of features, but solid, good, plumbing.
Will definitely be checking out and potentially replacing requests and aiohttp.
Httpx: A next-generation HTTP client for Python
91–100 of 119 posts
Re: Httpx: A next-generation HTTP client for Python
#92> Fully type annotated. This is a huge win compare to requests. AFAIKT requests is too flexible (read: easier to misuse) and difficult to add type annotation now. The author of requests gave a horrible type annotation example here [0]. IMO at this time when you evaluate a new Python library before adopting, "having type annotation" should be as important as "having decent unit test coverage". [0]: https://lwn.net/Art…
That's from 2015, his second complaint about interfaces vs inheritance is solved in recent versions with Protocols. Compatibility with 2.7 shouldn't be argument today either.
The complex union is as you say more a sign of a too flexible api rather than problem with type hints, the type hints just brings the root issue to the surface. I mean, why would you accept either a mapping or a list of tuples as input? Just let the user call dict(..) on the tuple-list first if they have it in such format? The documentation doesn't even mention that lists are ok for headers, only dicts: https://2.python-requests.org/en/master/api/#main-interface.
The file-tuple api with various length tuples is perhaps valid and the most convenient way to implement such options, but it's still an exceptionally unique api which requires exceptional type hints, it can be made slightly simpler which chc demonstrated above.
Re: Httpx: A next-generation HTTP client for Python
#93Earlier quoted context omitted.
some platforms do :) --> https://nim-lang.org/docs/httpclient.html
Indeed :) —> https://golang.org/pkg/net/http/ > Package http provides HTTP client and server implementations.
Re: Httpx: A next-generation HTTP client for Python
#94Too bad they carried over the biggest nuisance from requests, having to call raise_for_status() after every single request. One extra line everywhere and another thing that can be forgotten and cause strange errors when you least expect it.
Re: Httpx: A next-generation HTTP client for Python
#95What are the selling points for people already using aiohttp?
Maybe support for trio and HTTP/2?
Also I ran into hard-to-debug issues when there were lots of requests in the past. I'll check again with httpx soon.
Re: Httpx: A next-generation HTTP client for Python
#96FastAPI creator here... if you use FastAPI, HTTPX would probably be the best match for sending requests, just saying... :D
What does FastAPI actually add on top of Starlette which it’s built upon?
Re: Httpx: A next-generation HTTP client for Python
#97My project has a dozen or so libraries, many of which require different and conflicting requests, urllib3, etc., libraries. I have to setup the packages very carefully to ensure the right module gets the right version of its HTTP library and it has generally turned me off to Python HTTP libraries altogether. For my own code, I stick to the basic built-in libraries, regardless of how difficult to use they are.
Re: Httpx: A next-generation HTTP client for Python
#98Earlier quoted context omitted.
I want to mess with certs in Python so that my web crawler can actually access the whole web. If you don't talk to a wide variety of hosts, you probably haven't noticed that it's broken for 1%.
If you work in a corporate environment, you would probably notice that systems that insist on bundling their own certs without an easy to activate option of using system cert store are broken. (And even if the library has an easy to use option, if it's easy to not expose it, much software built on the library will still be broken.) People should be empowered to substitute cert stores, but the system store should be t…
A lot of corporate environments are fortunately legally bound and/or princilped about not doing mitm and are using the happy path of internet CAs.
Re: Httpx: A next-generation HTTP client for Python
#99Too bad they carried over the biggest nuisance from requests, having to call raise_for_status() after every single request. One extra line everywhere and another thing that can be forgotten and cause strange errors when you least expect it.
[deleted]
Re: Httpx: A next-generation HTTP client for Python
#100Too bad they carried over the biggest nuisance from requests, having to call raise_for_status() after every single request. One extra line everywhere and another thing that can be forgotten and cause strange errors when you least expect it.
Thoughts on this one [0]? :-)