Version 0.10.0

[lovelydinosaur]

Let's get squared away what we need for Version 0.10.0.

The key here is we need to make sure we've sorted out any API that'd block us from reintroducing the sync API, so...

• Let's drop .read() from Request - It's not documented anywhere, not actually required by users, and the content is available on request.stream if absolutely needed. Drop Request.read() #679
• We need Response.read() and Response.close() to be Response.aread() and Response.aclose(). The only point where this is relevant is users performing conditional reads inside a with httpx.stream(method, url) as response block. Rename 'read/close' to 'aread/aclose' on Response #674
• We ought to have Client.close() become Client.aclose() for consistency. Rename 'close' to 'aclose' on Client #675
• Good point to get Drop per-request cert, verify, and trust_env #617 in.
• We'll need to change response.next(). We could either underspecify the return type, and allow it to be either sync or async depending on the context, or we use response.anext() and response.next(). Rename 'next' to 'anext' on Response #676
• Good point to address Drop Origin from public API. #656.
• Potentially we could introduce an httpx.AsyncClient synonm for httpx.Client, and advise our users to switch towards that usage, so that there's no breaking changes for them once we fully reintroduce a sync API all the way through. Rename Client to AsyncClient (with compat synonym) #680

[florimondmanca]

We need Response.read() and Response.close() to be Response.aread() and Response.aclose().

We ought to have Client.close() become Client.aclose() for consistency.

I assume we want these changes to be backwards-compatible for 0.10, right? (Or should they error on usage?)

or we use response.anext() and response.next()

Keen on this, as it reflects gen.__next__() and async_gen.__anext__(). 👍

[florimondmanca]

Regarding .aclose() — I think we probably want to switch to that naming for all our other .close() operations too, if only for consistency.

In particular, this would be consistent with the overall convention in the async ecosystem — e.g. AsyncExitStack, async_generator's aclosing (async equivalent of contextlib.closing), etc.

[lovelydinosaur]

Pragmatically I think we probably just want to make the response/request changes and document them. If we don’t do that we’ll be blocked from reintroducing the sync API. They only affect anyone using conditional reads in streaming responses, and we’ve got clear messaging about pinning versions.

[florimondmanca]

If we don’t do that we’ll be blocked from reintroducing the sync API.

Yes, that's a good point. Same for Client, then, yes?

[lovelydinosaur]

Probably yes.

[lovelydinosaur]

I'm dropping the .origin issue for now.
We have PRs for all of these except the possible AsyncClient synonm, which we can probably also drop?

I'd suggest we issue a Version update pull request, with CHANGELOG and version update, just to allow a final once-over, then look at merge each of those 5 pull requests in and then issuing the release.

[florimondmanca]

We have PRs for all of these except the possible AsyncClient synonm, which we can probably also drop?

Well, I guess that depends what we'd like the final API to be like:

1. httpx.AsyncClient() / httpx.SyncClient()?
2. httpx.Client() / httpx.SyncClient()?

I think 1) is more natural, so I'd say bringing back AsyncClient as a synonym for Client does make sense for 0.10?