-
Notifications
You must be signed in to change notification settings - Fork 161
FEAT: args deprecation decorator #6086
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
Thanks for opening a Pull Request. If you want to perform a review write a comment saying: @ansys-reviewer-bot review |
@SMoraisAnsys @Samuelopez-ansys @Alberto-DM maybe we could think of merging the deprecate_kwargs with this new decorator? |
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.
Very nice! LGTM
I would keep them separated for clarity. One to remove arguments and one to modify their names. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6086 +/- ##
=======================================
Coverage 85.15% 85.15%
=======================================
Files 167 167
Lines 63124 63153 +29
=======================================
+ Hits 53754 53780 +26
- Misses 9370 9373 +3 🚀 New features to boost your workflow:
|
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 really like the idea behind this decorator and agree with @Alberto-DM, we should distinguish both decorators.
I've though a bit of the use cases we could face and I think it could be a good idea to customize the decorator a bit more. Here are some behavior we might want to add in order to pass information to our user:
- since: version where the argument was deprecated or deleted
- removed: states whether the argument was deleted or is just deprecated ftm
- custom_message: override the message that could be generated with other options
- action: raise a warning / raise an exception
- warning_category: type of warning to use (
DeprecationWarning
,FutureWarning
)
What do you think ?
@SMoraisAnsys yes, I agree. |
@SMoraisAnsys I added version and removed. What do you think? |
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.
You have added version
as a mandatory argument. You need to adjust the decorators calls.
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.
LGTM, I left a minor comment to make the message more consistent and handle multiple situations (with or without version provided).
Thanks for the changes !
Co-authored-by: Sébastien Morais <[email protected]>
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.
LGTM
Co-authored-by: pyansys-ci-bot <[email protected]> Co-authored-by: Sébastien Morais <[email protected]> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Description
In this PR I created a new decorator to deprecate arguments (whether they are positional or keywords) that will be removed in future versions. In this specific case I removed all analyze argument. We want to remove the possibility of analyzing the project within another method.
Issue linked
Please mention the issue number or describe the problem this pull request addresses.
Checklist