Conversation
|
@jd third and last PR here stacked on the second one. Please let me know if you prefer that I opened it against your |
tenacity/asyncio/retry.py
Outdated
| class _retry_always(retry_base): | ||
| """Retry strategy that always rejects any result.""" | ||
|
|
||
| async def __call__(self, retry_state: "RetryCallState") -> bool: # type: ignore[override] | ||
| return True |
There was a problem hiding this comment.
Is there a way for those function/classes to use the code from the sync ones? That'd avoid duplicating the logic everywhere.
There was a problem hiding this comment.
Good point. Besides, I also realised most of the implementations don't even need a redefinition as they are not performing any async operations. So I have removed most of the reimplementations and I've tried to DRY some of the others that use predicates, wdyt? c619e10
This implementation still looks somewhat odd to me though, I feel that combining sync and async retries may still yield some weird results, e.g. if the sync condition goes first in an &/| condition, then it will chain the rest as sync, which might not always work. Any suggestions to work around that? I was thinking of maybe referencing the async wrapper from the base class, but it sounds messy...
There was a problem hiding this comment.
I think I found a solution for the issue. I have rebased this PR onto main and added the changes there, would be great to get your thoughts on that 🙂 jd#451
|
Superseded by jd#451 |
2 participants
Third and last PR after breaking down jd#433 (follows #1)
Support async actions #1Support async actions jd/tenacity#437After DRYing the
iter()function and makingAsyncRetryingsupportasynccallbacks, add newasyncstrategies (basically a copy-paste) and improve typing.