Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Httpx: A next-generation HTTP client for Python

python-httpx.org

Post reply on HN
Print view View original

31–40 of 119 posts

Re: Httpx: A next-generation HTTP client for Python

#31

Post by westurner »

jordic wrote: post #23
yegle wrote: post #20

> 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…

The huge win against requests is that Https is fully async.. you can download 20 files in parallel without not too much effort. Throughout in python asyncio is amazing, something similar to node or perhaps better... That's the main point.

FWIW, requests3 has "Type-annotations for all public-facing APIs", asyncio, HTTP/2, connection pooling, timeouts, etc https://github.com/kennethreitz/requests3

Re: Httpx: A next-generation HTTP client for Python

#32

Post by fjp »

bbmario wrote: post #13

I 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?

Aiohttp + Aiopg which uses sqlalchemy

Re: Httpx: A next-generation HTTP client for Python

#33

Post by jannotti »

oefrha wrote: post #19
bbmario wrote: post #13

I 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?

> async web framework Not enough experience with async to comment. > DB peewee is good enough and more ergonomic compared to SQLA for a lot of use cases. > formatter black. To be clear it often produces truly horrendous code, but at least there’s no arguing and no fussing over options or details.

Yeah, it's weird that I find code formatted by black much less aesthetically pleasing than js code from prettier. But we're still using it.

Re: Httpx: A next-generation HTTP client for Python

#34

Post by oefrha »

grammarxcore wrote: post #26
oefrha wrote: post #3

One of the highlighted features is directly calling into WSGI applications[1], which uses flask as an example. Question: is there any advantage of this over flask’s builtin werkzeug test client? [1] https://www.python-httpx.org/advanced/#calling-into-python-w... [2] https://flask.palletsprojects.com/en/1.1.x/testing/

Comparing the code samples, it looks like it's easier to spin up testing with Httpx than Flask, but that's a superficial conclusion. I don't have experience with Httpx so take this with a grain of salt. Based on the comparison, I'm going to play with Httpx for testing the next time I use Flask because the simplicity looks rad. Based on similar experience with other tools, that possibly means that Httpx is great for s…

Flask’s sample code is doing a bunch of things like spinning up db and stuff and setting up a pytest fixture, so it’s not a fair comparison. You can replace

  with httpx.Client(app=app) as client:
      ...
in the httpx sample code with

  with app.test_client() as client:
      ...
for flask’s builtin test client and the rest is basically the same. Now that’s a fair comparison and neither is simpler than the other.

I guess one advantage of httpx is that developers might generally be more familiar with the requests response object API than the werkzeug response object API.

Re: Httpx: A next-generation HTTP client for Python

#36

Post by bouke »

korijn wrote: post #7

Is that another dead butterfly? Great package though. Love the dual support for async and sync requests.

I immediately wondered the same, and I think not. The upper wings are not at a 90 degree angle to the body, so alive and well. Apart from being a black and white drawing of course.

Re: Httpx: A next-generation HTTP client for Python

#37

Post by penagwin »

yegle wrote: post #20

> 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…

> "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" + 2 = "12" and no errors at all.

Re: Httpx: A next-generation HTTP client for Python

#38

Post by bransonf »

tiangolo wrote: post #22

FastAPI creator here... if you use FastAPI, HTTPX would probably be the best match for sending requests, just saying... :D

Sometimes I find it hard to justify all the time I spend on HN. But discovering FastAPI is probably going to compensate for plenty of this time.

This is a really awesome library, thanks!

Re: Httpx: A next-generation HTTP client for Python

#40

Post by ehsankia »

westurner wrote: post #31
jordic wrote: post #23

Earlier quoted context omitted.

The huge win against requests is that Https is fully async.. you can download 20 files in parallel without not too much effort. Throughout in python asyncio is amazing, something similar to node or perhaps better... That's the main point.

FWIW, requests3 has "Type-annotations for all public-facing APIs", asyncio, HTTP/2, connection pooling, timeouts, etc https://github.com/kennethreitz/requests3

Relevant blog and discussion:

https://vorpus.org/blog/why-im-not-collaborating-with-kennet...

https://news.ycombinator.com/item?id=19826680

Post reply on HN