Version 0.11.0

[tomchristie]

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 of httpx.Client().
• When instantiating proxy configurations use the httpx.Proxy() class, instead of the previous httpx.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, with httpx.AsyncClient being 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.origin property and httpx.Origin class are no longer available.
• The per-request cert, verify, and trust_env arguments 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 stream argument has escalated from raising an error when used, to no longer being available. Use the client.stream(...) or httpx.stream() streaming API instead.

Fixed

• Redirect loop detection matches against (method, url) rather than url. (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 Client as 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 Origin from public API. Drop Origin from public API #688
• Use httpx.Proxy() for proxy configuration, not the httpx.HTTPProxy dispatch class. Prep for introducing SyncClient #713
• Consider switching client.params, client.headers, client.cookies so that they don't have a setter/getter mismatch. Refs Make client.cookies setter expect a Cookies instance #678 use properties to allow more easily changing cookies/headers after init #274
• 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.Auth becomes public API. Public Auth API #732 Public API for auth flow. #731

[florimondmanca]

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?

[tomchristie]

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

• Always use a client instance.
• Use the 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]

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]

Still itching for httpx-native Retry functionality as a 1.0 API feature...

[tomchristie]

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]

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.

[tomchristie]

Dropping #678, #723 since they're not really a hard requirement here.

[jayvdb]

Note 0.10.1 hasnt been tagged.