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?
Httpx: A next-generation HTTP client for Python
51–60 of 119 posts
Re: Httpx: A next-generation HTTP client for Python
#52I 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?
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.
Re: Httpx: A next-generation HTTP client for Python
#53FastAPI creator here... if you use FastAPI, HTTPX would probably be the best match for sending requests, just saying... :D
Re: Httpx: A next-generation HTTP client for Python
#54Looks 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...
Re: Httpx: A next-generation HTTP client for Python
#55Re: Httpx: A next-generation HTTP client for Python
#56Re: Httpx: A next-generation HTTP client for Python
#57I 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?
Re: Httpx: A next-generation HTTP client for Python
#58> 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"…
Re: Httpx: A next-generation HTTP client for Python
#59Re: Httpx: A next-generation HTTP client for Python
#60I 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.