Repository navigation
Version 0.12 #829
Description
So, I've issued a first release of httpcore - the intent is that we should switch over from our existing dispatchers (urllib3 for sync, our own ConnectionPool for async) to the httpcore dispatchers (SyncConnectionPool and AsyncConnectionPool).
The benefits for us doing so would be:
- We'll have a really nice strict seperation of concerns between the networking layer, and the cilent smarts layer.
- We'll have consistent network behavior across both sync + async (rather than urllib3 in one case.)
*Able to drop theurllib3dependancy, although we'll keep theurllib3dispatcher as an optional alternative. - In a postion to make promote the dispatch interface into public API.
- Tighter management of connection pool state changes. Resolves Issuing requests in close concurrency can unneccessarily result in multiple HTTP/2 connections. #514, Open new HTTP/2 connections when stream space is exhausted. #283. (I'll also take a look at #282 at some point.)
I guess we're probably in a position to push for doing that in 0.12 release if we wanted, although it means significant churn so I think we should certainly issue a pre-release if that's what we want to do.
The #804 PR goes a long way towards switching around the interface to allow us to plug into it, although there's still a little more that'd need doing there (changing the url signature to Tuple[bytes, bytes, int, bytes], changing the init arguments for httpcore.AsyncConnectionPool somewhat.)
Other PRs that look like they ought to go in...
- Drop
backendfrom Client. Drop backend parameter on AsyncClient #791 - Fix
datato not erronously accept dict-of-dicts. Don't support broken dict-of-dicts case for data argument. #811 - Ensure that
Client.close()closes proxies. Close proxy dispatch classes on Client.close() #826
Any more?
We'd also need to drop UDS support if we want to get httpcore in. I should have pushed back harded on it in the first place - as nice as it is to have features++ it doesn't really make the "feature set we need to focus on for 1.0".
I'd also really appreciate anyone kicking the tyres of httpcore a bit. It could do with some documentation love, but there should be enough there for folks to give it a first try.
What do we think? Is this a sensible point to aim at switching out to our unasync'ed backend? Is there anything I'm missing in considering this for a 0.12 release?
Activity
florimondmanca commentedon Feb 27, 2020
Awesome work on getting a first HTTPCore release out there!
I haven't been very active around here lately, but overall the plan proposed here sounds good to me.
Although I might be tempted to have the bunch of current PRs in a 0.12 release, and then bring HTTPCore and unasync etc in 0.13? My rationale here would be, "let's get as much out of the way before switching the internals to HTTPCore". Perhaps we've also got a bunch of small fixes here and there that might benefit from being release soon rather than waiting for HTTPCore?
Alright, yeah. The
(scheme, host, port, path)form of the URL specified byhttpcoredoesn't fit the UDS, so I can see why. Fine to have that as third-party in the end I guess. :-)florimondmanca commentedon Feb 29, 2020
Ideally I'd like us to have #836 and then #23 (docs PRs) for the next release as well…
victoraugustolls commentedon Mar 1, 2020
I could gladly help, if that’s desirable! I’m using httpx a lot in the place I work. All of our new miroservices use it (with FastAPI), and although I’m running into some problems that need better understanding, I would love to make this library the goto standard for http communication in the future for any python developer!
florimondmanca commentedon Mar 1, 2020
Shold we consider resolving #302 part of the roadmap to 1.0?
lovelydinosaur commentedon Mar 2, 2020
@florimondmanca Nope not really. It's not an API blocker, so as much as I'd like to see any progress there, we've not got any need to block "this is the 1.0 API" against it.
florimondmanca commentedon Mar 4, 2020
@tomchristie
Looks like all PRs that ought to get in for 0.12 got merged. We already have a few pending fixes that haven't been released yet (0.11.1 dates from Jan 17), eg #780, #803, #814, #819, #796.
I think we should issue 0.12 soon, and only look at unasync/bringing httpcore in for 0.13, WDYT?
lovelydinosaur commentedon Mar 5, 2020
Seems like a sensible tack, yup.