Repository: encode/httpx

Issue:
ASGIDispatch and WSGIDispatch should be importable from the top-level httpx package
From #396:

> ``ASGIDispatch`` and ``WSGIDispatch`` are documented as top-level but aren't exposed at the top level. This is definitely an issue, I'd recommend the route of making both available top-level.


Discussion:
Thanks for opening this, yup.

Either we need to switch the docs around *or* we need to make them top-level importable.
I'm not entirely sure yet which of those two we ought to prefer.
I think if it's important enough to show in the prose docs, it should be top-level. Or, at least, be ``httpx.dispatch.ASGIDispatch``/``httpx.dispatch.WSGIDispatch``. This is probably true for other things in ``httpx`` as well.
Considering most public pieces of API are top level importable (which also supports the use case of accessing members of the httpx package), I’d advocate for that path as well.
> I think if it's important enough to show in the prose docs, it should be top-level.

Indeed - that's the general rule we've been going with.

A *few* aspects such as concurrency backends we'd like to be more tightly namespaced, rather than always pulling them all the way up to the top level.

It's *possible* that `middleware`, `dispatch`, and `concurrency` are cases where we actually *do* want seperation rather than always hoisting everything to the top, and having a very top heavy namespace.
> It's _possible_ that `middleware`, `dispatch`, and `concurrency` are cases where we actually _do_ want seperation rather than always hoisting everything to the top, and having a very top heavy namespace

I'm definitely fine with that if that's what the team wants to stick to. But making sure people just have to use the namespace rather than needing the actual module (``httpx.dispatch.ASGIDispatch`` vs ``httpx.dispatch.asgi.ASGIDispatch``).

As I pointed out in another issue, there is inconsistency in what is exported from these namespaces right now. I also see that ``__all__`` is only used at the top level; it should probably be used everywhere. It's also not sorted and at the bottom instead of top, making it harder to find/read. Should there be a more judicious use of ``__all__`` in httpx?
> > It's _possible_ that `middleware`, `dispatch`, and `concurrency` are cases where we actually _do_ want seperation rather than always hoisting everything to the top, and having a very top heavy namespace.

> I'm definitely fine with that if that's what the team wants to stick to. But making sure people just have to use the namespace rather than needing the actual module (httpx.dispatch.ASGIDispatch vs httpx.dispatch.asgi.ASGIDispatch).

Seconded.
Could you assign me this issue, if it's up for grabs ?

I believe this is the way to go.
> I'm definitely fine with that if that's what the team wants to stick to. But making sure people just have to use the namespace rather than needing the actual module (httpx.dispatch.ASGIDispatch vs httpx.dispatch.asgi.ASGIDispatch).

Also what might be you suggestion for this 

> As I pointed out in another issue, there is inconsistency in what is exported from these namespaces right now. I also see that __all__ is only used at the top level; it should probably be used everywhere. It's also not sorted and at the bottom instead of top, making it harder to find/read. Should there be a more judicious use of __all__ in httpx?
@mxahmed Let's start with importing it at the top level, there's a lot more work to do if we move towards not pulling everything to the top level package.
@sethmlarson Alright then.

Resolving patch:
diff --git a/httpx/dispatch/__init__.py b/httpx/dispatch/__init__.py
--- a/httpx/dispatch/__init__.py
+++ b/httpx/dispatch/__init__.py
@@ -2,3 +2,7 @@
 Dispatch classes handle the raw network connections and the implementation
 details of making the HTTP request and receiving the response.
 """
+from .asgi import ASGIDispatch
+from .wsgi import WSGIDispatch
+
+__all__ = ["ASGIDispatch", "WSGIDispatch"]


Test patch: