Some API oddities/possible oversights

While I was working on porting my google-music library to httpx using pared down oauth2 code borrowed from requests-oauthlib (see the quick stab at it here if interested), I noticed some API oddities/differences from requests even with the relatively small amount of usage in my library.

• BasicAuthMiddleware, previously HTTPBasicAuth, is not available at the top level of the package, nor any other middleware aside from DigestAuth. The current naming inconsistency between the two is also strange. Both are middleware, and it was named HTTPBasicAuth in requests and previously in httpx. Though I could certainly see the inconsistency being DigestAuth as all other middleware, including CustomAuthMiddleware, follow the same pattern. I think something needs to happen as far as the exposing, organizing, and making consistent of things like this. What that thing is, I’m not sure. Quick opinion is that these classes being middleware is more of an implementation detail than anything else. I’d expect the auth classes to be exposed through auth like previously and in requests or at the top level. I’d also expect them without “Middleware” in the names (possibly just aliased).

• HTTPError is not available at the top level like the other exceptions and like it was in requests. This is a somewhat common exception to catch raise_for_status, so having to add another import statement for it is a bit odd if intentional.

• requests.Session has a params attribute that attaches those params to each session request. This is not present in httpx Client classes like with headers/cookies. This is a useful feature for this and other use cases of mine and a divergence from requests.

Thanks for all the work. Been excited about httpx since the beginning. Glad to finally start using it more. Interested in seeing the discussion around these points.

[florimondmanca]

@subfxnet There aren’t current plans to make it public, no, as we might be heavily reworking this part of HTTPX soon. I believe this is something we’d like to eventually provide, though.

[StephenBrown2]

Aliasing but raising a DeprecationError for the aliases with a link to the migration docs would be a good middle path to take IMHO.