-
Notifications
You must be signed in to change notification settings - Fork 0
retry generator + tests #2
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
Conversation
|
@amiruci I will be updating https://github.com/CloverHealth/clover_pipeline/pull/5117 shortly. |
|
lgtm |
| .. code:: python | ||
| def retry(exceptions=Exception, tries=-1, delay=0, max_delay=None, backoff=1, jitter=0, logger=logging_logger): | ||
| def retry(exceptions=Exception, tries=-1, delay=0, max_delay=None, backoff=1, jitter=0, logger=logging_logger, generator=False): |
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.
Python compiles generator functions in a different fashion than regular functions, you can determine this via inspection instead of requiring the user to know whether a function is a generator or not: https://docs.python.org/3/library/inspect.html#inspect.isgeneratorfunction
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.
I was requiring the user to do so here to ensure no change in interface.
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.
how do you mean "no change in interface"?
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.
Say you have this method:
def foo():
for x in y:
yield x
Before this PR, you could @retry foo and expect certain behaviors. I don't want to change that behavior, instead requiring the developer to use generator=True to change behavior in that scenario.
| return __retry_internal(partial(f, *args, **kwargs), exceptions, tries, delay, max_delay, backoff, jitter, | ||
| logger) | ||
| pf = partial(f, *args, **kwargs) | ||
| if generator: |
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.
if inspect.isgeneratorfunction(f):
...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.
See my other comments on interface. I could, however, error if generator and not inspect.isgeneratorfunction(f).
gwax
left a comment
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.
Broadly speaking, I worry that this is a dangerous tool if misused with particularly tricky edge cases around restarting a generator. I do not expect that users of this would necessarily know enough to avoid those pitfalls when wrapping a generator with @retry
I'll defer to you on this, particularly because you have more context around developers at Clover. |
|
Closing PR per @gwax recommendation we don't want to use this at Clover. I'm also going to deprecate this fork because using a fork of a python package is a bit cumbersome based on how we currently do package management. |
See invl#16