-
-
Notifications
You must be signed in to change notification settings - Fork 281
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
Incrementally build iter actions list #434
Conversation
|
tenacity/__init__.py
Outdated
try: | ||
return self._local.iter_state # type: ignore[no-any-return] | ||
except AttributeError: | ||
self._local.iter_state = t.cast(t.Dict[str, t.Any], {}) |
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.
Can we have something either more structured or split?
I am no fan of having a dict with Any
and random keys TBH.
At least a TypedDict
?
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.
Sounds fair, wdyt? 538686b
tbh I just copied the approach from the statistics
property, and I was tempted to change the local()
implementation for a ContextVar
and maybe introducing dataclass
es, but seemed like a bit too much to do together with these changes. Maybe something to tackle separately if that's something you'd like to see.
@jd I noticed |
I switched the project to ruff to solve this. |
Thanks @jd! Just re-formatted the changes with |
|
@jd how would you want to go about the chain of PRs? Do you want me to add a |
As long as there is no external changes, we can skip the changelog entry. |
First PR after breaking down #433
Support async actions hasier/tenacity#1Support async actions #437Add async strategies hasier/tenacity#2Add async strategies #451An attempt at DRYing the
iter()
function in order to supportasync
callbacks.The approach I have taken is to build a list of actions that
iter()
needs to go through, where each action is just a piece of the whole current logic, and each step can further extend the list of actions. 3 pieces have been taken out to redefine in specific Retrying implementations, i.e.asyncio
. This way we can make sure we use coroutines for those calls, as well as dynamically wrapping each function as a coroutine, allowing for both sync and async strategies and callbacks.