Live data from Hacker News

Httpx: A next-generation HTTP client for Python

python-httpx.org

51–60 of 119 posts

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

#51
post #6

Finally a client that mixes async support and a “requests-compatible” API (for those times you don’t want to go as low as say an aiohttp or the like). Looking forward to trying it out Edit: maybe the homepage can include a very simple async example as well?

As an aiohttp user, what do you mean? The API od aiohttp is not low level and is very similar to requests api.

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

#52
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?

I used aiohttp and it is quite good and solid (I also like that it comes with type annotations, which enables autocomplete in PyCharm), I did not have chance to compare it to FastAPI.

Regarding database access, my recommendation might not be popular, but I really like asyncpg[1]. They basically dropped DBAPI and instead created their own API that functionally matches PostgreSQL, giving you full control and increasing performance.

As a result of that you probably won't be able to use ORMs (there's SQLAlchemy driver, but as I understand it is hacky and you are losing the performance benefits).

Personally I compared my code with and without ORM and there's no change in number of lines. If you use PyCharm and configure it to connect to your database (I think that might be a pro feature) it will then automatically detect SQL in your strings provide autocomplete (including table and column names) and provide highlighting, removing all the advantages that ORM provided.

[1] https://github.com/MagicStack/asyncpg

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

#54
post #43
post #42

Looks like this does not include certifi [0] and loads system certificates by default. This is a breath of fresh air to see, because so many packages want to use their own certs and have a custom system to override it to use system certs. Edit: Well, looks like it does use certifi. But my grumble still stands, I don't understand why does everyone want to mess with your certs. [0] https://pypi.org/project/certifi/

It uses certifi by default, and it's down in the dependencies: https://www.python-httpx.org/advanced/#changing-the-verifica...

Bummer. Luckily, it doesn't invent a new way to override, `SSL_CERT_FILE` is mentioned in the environmental variables.

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

#56

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

https://fastapi.tiangolo.com/ Looks great!

Incredible! Just started with python, this looks pretty good to use.

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

#57
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?

Starlette, by the same author as httpx.

https://www.starlette.io/

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

#58
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"…

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.

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

#60
post #18

I 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
Post reply on HN