Repository: encode/httpx

Issue:
Version 0.11.0
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.

```python
>>> 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 #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

- [x] Reintroduce `Client` as a sync client. #735
- [x] Reintroduce `WSGIDispatch`. #735
- [x] Top-level API becomes sync, not async. #735
- [x] Drop `Origin` from public API. #688
- [x] Use `httpx.Proxy()` for proxy configuration, not the `httpx.HTTPProxy` dispatch class. #713
- [ ] ~Consider switching `client.params`, `client.headers`, `client.cookies` so that they don't have a setter/getter mismatch.~ Refs #678 #274
- [ ] ~Consider dropping UDS support.~ #723
- [x] Wrap IO Exceptions in httpx exceptions. #707
- [x] Docs #727
- [x] `httpx.Auth` becomes public API. #732 #731



Discussion:
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?
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?
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?
Still itching for `httpx`-native Retry functionality as a 1.0 API feature...
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.
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.
Dropping #678, #723 since they're not really a hard requirement here.


Resolving patch:
diff --git a/httpx/__version__.py b/httpx/__version__.py
--- a/httpx/__version__.py
+++ b/httpx/__version__.py
@@ -1,3 +1,3 @@
 __title__ = "httpx"
 __description__ = "A next generation HTTP client, for Python 3."
-__version__ = "0.10.1"
+__version__ = "0.11.0"
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -62,7 +62,7 @@ def get_packages(package):
         "urllib3==1.*",
     ],
     classifiers=[
-        "Development Status :: 3 - Alpha",
+        "Development Status :: 4 - Beta",
         "Environment :: Web Environment",
         "Intended Audience :: Developers",
         "License :: OSI Approved :: BSD License",


Test patch: