Repository navigation
Version 0.11.0Β #724
Description
This one is a big deal, since it reintroduces the sync client, and is essentially a 1.0 pre-release in terms of how the API looks.
>>> import httpx
>>> httpx.get('https://www.example.com')
<Response [200 OK]>πβ¨ TA-DA! β¨π
Release notes
0.11.0 (January 9th, 2019)
The 0.11 release reintroduces our sync support, so that httpx now supports both a standard thread-concurrency API, and an async API.
Existing async httpx users that are upgrading to 0.11 should ensure that:
- Async codebases should always use a client instance to make requests, instead of the top-level API.
- The async client is named as
httpx.AsyncClient(), instead ofhttpx.Client(). - When instantiating proxy configurations use the
httpx.Proxy()class, instead of the previoushttpx.HTTPProxy(). This new configuration class works for configuring both sync and async clients.
We believe the API is now pretty much stable, and are aiming for a 1.0 release sometime on or before April 2020.
Changed
- Top level API such as
httpx.get(url, ...),httpx.post(url, ...),httpx.request(method, url, ...)becomes synchronous. - Added
httpx.Client()for synchronous clients, withhttpx.AsyncClientbeing used for async clients. - Switched to
proxies=httpx.Proxy(...)for proxy configuration. - Network connection errors are wrapped in
httpx.NetworkError, rather than exposing lower-level exception types directly.
Removed
- The
request.url.originproperty andhttpx.Originclass are no longer available. - The per-request
cert,verify, andtrust_envarguments are escalated from raising errors if used, to no longer being available. These arguments should be used on a per-client instance instead, or in the top-level API. - The
streamargument has escalated from raising an error when used, to no longer being available. Use theclient.stream(...)orhttpx.stream()streaming API instead.
Fixed
- Redirect loop detection matches against
(method, url)rather thanurl. (Pull Fixed redirect loopΒ #734)
What's next...
I'd expect that we'll likely end up waiting for a period of time after this release, and then end up releasing a 1.0 with either no API changes, or only very minimal API changes. (The only remaining area I can see us still wanting to refine/change, would be some review making sure we've got an exception heirarchy/naming that we're entirely happy to stick with for 1.0 onwards)
Checklist
- Reintroduce
Clientas a sync client. Reintroduce sync API.Β #735 - Reintroduce
WSGIDispatch. Reintroduce sync API.Β #735 - Top-level API becomes sync, not async. Reintroduce sync API.Β #735
- Drop
Originfrom public API. DropOriginfrom public APIΒ #688 - Use
httpx.Proxy()for proxy configuration, not thehttpx.HTTPProxydispatch class. Prep for introducing SyncClientΒ #713 -
Consider switchingRefs Make client.cookies setter expect a Cookies instanceΒ #678 use properties to allow more easily changing cookies/headers after initΒ #274client.params,client.headers,client.cookiesso that they don't have a setter/getter mismatch. -
Consider dropping UDS support.Consider pushing back on UDS support.Β #723 - Wrap IO Exceptions in httpx exceptions. Wrap network errors as HTTPX-specific exceptionsΒ #707
- Docs Proposed 0.11 docsΒ #727
-
httpx.Authbecomes public API. Public Auth APIΒ #732 Public API for auth flow.Β #731
Activity
florimondmanca commentedon Jan 6, 2020
I think the breaking in this release should not be underestimated from a user perspective. Granted, weβre still pre1.0, but a second abrupt round of breaking changes after 0.8 dropped sync might not be what we need.
So while I agree with basically reswitching from async to sync as the default, Iβm thinking of ways we could help users migrate.
At the very least we could probably add a migration guide item to this checklist, as a prose-form and hand-guided tour of the change log, with hints on migrating a codebase that uses 0.10. Thoughts?
lovelydinosaur commentedon Jan 6, 2020
Things we could potentially could defer, pass-on, or mitigate: #678, #723.
The big one is the sync API, which for our existing users means...
httpx.AsyncClient()naming.If we're very clear about that, then I think the "okay we're done here API-wise" trade-off is probably worth it?
florimondmanca commentedon Jan 6, 2020
Yes, those recommendations sound like a good plan to provide some proactive communication. Should we roll them out now, i.e. some time before 0.11 is out?
StephenBrown2 commentedon Jan 6, 2020
Still itching for
httpx-native Retry functionality as a 1.0 API feature...lovelydinosaur commentedon Jan 6, 2020
Sure, I could potentially see us including that.
Few things higher up on the priority list still atm, and wouldnβt strictly need to be a 1.0 feature (ie add more features/API post 1.0 is totally fine, the cutoff is for making sure any API we have introduced is in a final state.)
But yeah may not be a bad idea.
iwoloschin commentedon Jan 7, 2020
A big +1 for built-in retry, though I've made a very simple and very silly recursive retry wrapper that appears to work reasonably well, other than polluting up your stack trace when something does go wrong.
lovelydinosaur commentedon Jan 7, 2020
Dropping #678, #723 since they're not really a hard requirement here.
jayvdb commentedon Jan 8, 2020
Note 0.10.1 hasnt been tagged.