-
Notifications
You must be signed in to change notification settings - Fork 418
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Beta: Collapse HTTPClientAsync into HTTPClient #1239
Conversation
48b6b04
to
5877097
Compare
fba5cfd
to
46f7a24
Compare
LGTM though also tagging Annie. Just one clarifying question for my understanding, what would be a case where a user uses |
I expect this to be rare but I can contrive an example: suppose you are a user migrating to
then you can't use async. If you switch to
then you can begin to use async piece by piece, but you have inadvertently caused the entire sync integration to switch over to HTTPX instead of Requests. If you really want the migration to httpx/async to be done piecemeal you can
Should we make I lean towards keeping it public. It would feel weird to me if the |
I agree, am peaceful with keeping it public. Thanks for the explanation! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes sense to me, thanks for the thoughtful PR description with pros / cons and drive-by clean-up of the http_client_mock interface!
Summary
This
HTTPClientAsync
and adds its methods directly ontoHTTPClient
.HTTPClientBase
too, as there is now only one class that inherits from it and it was introduced explicitly forHTTPClientAsync
HTTPClient
constructor optionally accept a new parameterasync_fallback_client
. Calls to async methods will be handled by the fallback client if it is present, instead of raising "NotImplemented".api_requestor
andstripe_client
so that they dostripe.default_http_client = new_default_http_client(...)
(as they do when the user provides no custom http client), a fallback client is provided (HTTPXClient or NoImportFoundAsyncClient).Details
I have chosen a design where
This avoids some ambiguity in cases like
If this created a fallback client automatically, should the
timeout=5
be forwarded through to thestripe.HTTPXClient
? What if "timeout" means something different onstripe.RequestsClient
than it does onstripe.HTTPXClient
?On the other hand, it does means fewer people will be able to upgrade their library, add await and "_async" to all their stripe method calls and have it Just Work™️ . (Things will Just Work™️ for people who use the defaults, but not for anybody making custom instances of Stripe's built-in http clients.)
Changelog
stripe.default_http_client_async
global and thestripe.HTTPClientAsync
class.stripe.default_http_client
to a subclass ofstripe.HTTPClient
such asstripe.HTTPXClient
that implements.request_async
,.sleep_async
,.request_stream_async
, and.close_async
.RequestsClient
for synchronous methods, that "falls back" to aHTTPXClient
when asynchronous methods are called.