Repository navigation
Version 0.10.0 #667
Description
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()fromRequest- It's not documented anywhere, not actually required by users, and the content is available onrequest.streamif absolutely needed. Drop Request.read() #679 - We need
Response.read()andResponse.close()to beResponse.aread()andResponse.aclose(). The only point where this is relevant is users performing conditional reads inside awith httpx.stream(method, url) as responseblock. Rename 'read/close' to 'aread/aclose' on Response #674 - We ought to have
Client.close()becomeClient.aclose()for consistency. Rename 'close' to 'aclose' on Client #675 - Good point to get Drop per-request
cert,verify, andtrust_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 useresponse.anext()andresponse.next(). Rename 'next' to 'anext' on Response #676 -
Good point to addressDropOriginfrom public API. #656. - Potentially we could introduce an
httpx.AsyncClientsynonm forhttpx.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
Activity
florimondmanca commentedon Dec 21, 2019
I assume we want these changes to be backwards-compatible for 0.10, right? (Or should they error on usage?)
Keen on this, as it reflects
gen.__next__()andasync_gen.__anext__(). 👍florimondmanca commentedon Dec 21, 2019
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'saclosing(async equivalent ofcontextlib.closing), etc.lovelydinosaur commentedon Dec 21, 2019
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 commentedon Dec 21, 2019
Yes, that's a good point. Same for
Client, then, yes?lovelydinosaur commentedon Dec 21, 2019
Probably yes.
lovelydinosaur commentedon Dec 22, 2019
I'm dropping the
.originissue for now.We have PRs for all of these except the possible
AsyncClientsynonm, 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 commentedon Dec 22, 2019
Well, I guess that depends what we'd like the final API to be like:
httpx.AsyncClient()/httpx.SyncClient()?httpx.Client()/httpx.SyncClient()?I think 1) is more natural, so I'd say bringing back
AsyncClientas a synonym forClientdoes make sense for 0.10?florimondmanca commentedon Dec 23, 2019
I pushed a PR for the
AsyncClientrenaming, so at least we've got it ready if we want it to land in 0.10 (and I think we should?).lovelydinosaur commentedon Dec 23, 2019
Milestoned everything that we think is going into this.
I thin we prep the release notes before we merge, just to give us a final once over.
(I'd like them to also note the motivation for the changes here)