With all the alleged drama surrounding the requests module and the promised async support, I am pleased there is a drama-free alternative.
https://vorpus.org/blog/why-im-not-collaborating-with-kennet...
Httpx: A next-generation HTTP client for Python
61–70 of 119 posts
Re: Httpx: A next-generation HTTP client for Python
#62I don't understand why this is such a complicated category and that many platforms do not have solid http clients in standard library. On every single project I do, it's just a bunch of posting JSON and getting a response synchronously. Over and over.
Plenty of reason why it's hard to ship in standard library. Here's some off top of my mind: - Should the library includes its own CA store, or use the system's CA store? These kind of library often include their own CA store (since they changes often), and httpx seem to use 3rd party lib to handle that (certifi). This is hard to do in a standard library for variety of reasons (users rarely update their python install…
HTTP/2 was only standardized 4 years ago. HTTP/3 is being actively developed. That's actually not really stable on a language's standard library timespan, IMHO.
Re: Httpx: A next-generation HTTP client for Python
#63With all the alleged drama surrounding the requests module and the promised async support, I am pleased there is a drama-free alternative. https://vorpus.org/blog/why-im-not-collaborating-with-kennet...
[deleted]
Re: Httpx: A next-generation HTTP client for Python
#64Earlier quoted context omitted.
> "having type annotation" should be as important as "having decent unit test coverage". I mean this is pretty spot on IMO. I've worked with many languages, and have concluded that having a powerful type system catches soooo many bugs before you even try to run the code. And they're usually "stupid" bugs too, forgetting to sanitize inputs etc. Even worse is when a language tries to be "smart", so you end up with "1"…
Type systems and static checks in general are great. What do you think of the example type in the post above? It seems like the type system might not be expressive enough to handle existing APIs, that’s something which was hard for TypeScript too, but has slowly been getting better. Perhaps that will be the case in Python too.
You should check out the Literal type in Python. It provides for some of the stupider things in libraries, like return types that vary based on the value of an input parameter, as in Python’s open() method, which might return a text stream or a bytestream based on the value of the second parameter.
Re: Httpx: A next-generation HTTP client for Python
#65One thing requests still has going for it is that it’s used under the covers by a lot of client libraries with a dynamic import, allowing you to pass in a session object to control things like connection pooling and custom headers.
I do look forward to httpx becoming the new “standard” though. Tom is a great developer, and his ecosystem of tools are going to have a really big impact in python web dev over the coming years.
Re: Httpx: A next-generation HTTP client for Python
#66I like async support, but always, in async examples, doesn't the await keyword just block anyways?
I like to see the usage of async inside of a main loop, where other things can be processed while waiting for the async response to come in.
Further, not all applications have the idea of an event loop, so async may not be needed, but it's useful to have the option.
I use async operations to multiplex operations in a queue. The linux scheduler can handle the execution time slices for me, I'm not going to build a scheduler, but the queue controller's role is to accept jobs and handle timeouts and results of each async operation.
Re: Httpx: A next-generation HTTP client for Python
#67I don't understand why this is such a complicated category and that many platforms do not have solid http clients in standard library. On every single project I do, it's just a bunch of posting JSON and getting a response synchronously. Over and over.
It's simple. Python was created before HTTP even existed. Since then a lot of things had changed, and once you create an API, it is hard to rewrite it when new use patterns emerge. It's easier for a 3rd party package to come up with a better api, because they can start brand new. Also when there's a radical change it is easier for a new 3rd package to take over. Httpx is example of such evolution, although not due to…
Python was created before json existed, and yet: https://docs.python.org/3/library/json.html
It's not a hard rule, sometimes things do end up in the standard library.
Re: Httpx: A next-generation HTTP client for Python
#68I know this is unrelated, but probably a lot of Pythonistas here and I've been wondering: what is the async web framework of choice for you guys today? As for DBs, still SQLAlchemy? What about a prettier (js) alternative?
I’ve been a very happy Tornado user for years.
Re: Httpx: A next-generation HTTP client for Python
#69I don't understand why this is such a complicated category and that many platforms do not have solid http clients in standard library. On every single project I do, it's just a bunch of posting JSON and getting a response synchronously. Over and over.
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
#70I don't understand why this is such a complicated category and that many platforms do not have solid http clients in standard library. On every single project I do, it's just a bunch of posting JSON and getting a response synchronously. Over and over.
I blame the bloat. In some high-level languages even BSD sockets (and many other POSIX functions) aren't in the standard library, and there are various wrappers to provide "ease of use" and integration with a language's runtime system; plenty of complexity (and alternatives) even at that point. RFC 2616 (HTTP/1.1, 1999) may seem manageable, but it's much more than just posting data and getting a response, and IME man…
> RFC 2616 (HTTP/1.1, 1999) may seem manageable
But it's probably not, as it's underspecified and ambiguous, which is part of why its been replaced as the HTTP/1.1 spec by RFCs 7230-7237 (2014).