-
-
Notifications
You must be signed in to change notification settings - Fork 622
Fixed mypy sp check guidelines #4887
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
base: develop
Are you sure you want to change the base?
Conversation
Still 25 mypy errors are left, drafting this so that its easier to communicate changes |
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.
Thanks, I've triggered the workflows! I haven't reviewed all the files, because I understand that the PR is still a draft and you have yet to complete the changes.
Checking https://learn.scientific-python.org/development/guides/repo-review/?repo=pybamm-team/pybamm, a few more rules where we have problems have popped up. So we shouldn't mark this PR as one that closes the linked issue. Could you please replace the "Fixes" keyword in the PR description with "Related to"?
It is also possible to add sp-repo-review
as a pre-commit hook so that new rules will be checked on every commit. I think we should investigate that and add it if running the checks is not too slow. I'm also curious to hear what @Saransh-cpp has to say about this.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #4887 +/- ##
===========================================
- Coverage 98.71% 98.70% -0.01%
===========================================
Files 304 304
Lines 23509 23542 +33
===========================================
+ Hits 23207 23238 +31
- Misses 302 304 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
It would be great to have repo-review as a pre-commit hook! @agriyakhetarpal maybe you can create a new independent issue for that? |
I've changed the PR description to related to and I also think it would be great to have a pre-commit hook for |
I've fixed the remaining errors too |
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.
Thanks for taking this up, @Rishab87! See my comment below about splitting this PR.
@@ -252,6 +252,10 @@ concurrency = ["multiprocessing"] | |||
ignore_missing_imports = true | |||
allow_redefinition = true | |||
disable_error_code = ["call-overload", "operator"] | |||
strict = 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.
Given how big this PR is, it would actually be better to split it into multiple PRs, each one adding a new config option in pyproject.toml.
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.
ok so should I go ahead then and make a PR on one of the config first? or edit this one accordingly?
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 can keep this PR for one config, and add other configs in subsequent PRs.
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.
ok I'll create seperate PRs for different configs and then keep this one for the end, I think that would be faster for me
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 noticed many of the warn_unreachable
error depends on errors from enable_error_code
config, they're related to each other and their are total of 77 errors out of which 57 are from enable_error_code
so I think creating a seperate PR would still be almost as big as this one, so should I still proceed with it?
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.
Yes, I think anything that reduces the diff and keeps this PR scoped to a specific change (or a few of them) would be great. Thanks for investigating!
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've created the PR with just enable_error_code
config: #4891, sorry for the delay lab tests going on
Co-authored-by: Saransh Chopra <[email protected]>
@@ -48,7 +49,7 @@ | |||
disc.process_model(model) | |||
|
|||
# solve model | |||
solutions = [None] * len(models) | |||
solutions: Any = [None] * len(models) |
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.
Shouldn't this be something like list[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.
yess, I'll change that
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.
Thanks, @Rishab87! It is not fully clear from some of the changes as to why they were made, could you please highlight them and tell us what was fixed where? Some changes also seem to change the logic in a few places; documenting it is important.
examples/scripts/heat_equation.py
Outdated
@@ -106,7 +106,7 @@ def T_exact(x, t): | |||
# Plot ------------------------------------------------------------------------ | |||
x_nodes = mesh["rod"].nodes # numerical gridpoints | |||
xx = np.linspace(0, 2, 101) # fine mesh to plot exact solution | |||
plot_times = np.linspace(0, 1, 5) | |||
plot_times: np.ndarray = np.linspace(0, 1, 5) |
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 should be npt.NDArray (see #4899).
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.
changed this
# Check right is pybamm Symbol | ||
if not isinstance(right, pybamm.Symbol): |
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.
Could you please explain why this check was modified?
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 getting
error: Left operand of "and" is always true [redundant-expr]
but I think now this should not be modified, this seems weird that its not showing this for right symbol as its also going through the same checks above
def _new_instance(self, left: pybamm.Symbol, right: pybamm.Symbol) -> pybamm.Symbol: | ||
return Power(left, right) | ||
|
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.
Why do we need new _new_instance
methods? Could you document this in an inline comment somewhere, or add it in the PR description (better)?
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've added new_instance because earlier when we were using __ class __ it showed a third arg was not getting passed:
error: Missing positional argument "right_child" in call to "BinaryOperator" [call-arg]
but this function was always getting called from child classes of BinaryOperator which don't need to pass 3 arguments, so i thought it was better to make a new_instance method which can be overirded in child classes
so should I update the PR description or think of some other approach?
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.
And for broadcasts.py self.broadcast_domain was not defined in parent class they were params of child classes and _unary_new_copy function was getting called from child class instance always so I just overrided this function in child classes, apart from these changes all other changes are mostly type changes
…sp-check-guidelines
@agriyakhetarpal Thanks for the review, I've left comments for the major changes, should I write these major changes in PR description too? |
Yes, please do! |
@agriyakhetarpal I've updated the PR description, can you please review it? |
Description
Fixing mypy sp check guidelines
Some major changes I did:
In
src/pybamm/expression_tree/binary_operators.py
I've replacedself.__ class __
in line 131 with new_instance because earlier when we were usingself.__ class __
it showed a third arg was not getting passed:but this function was always getting called from instance of its child classes which don't need to pass 3 arguments, so i
thought it was better to make a new_instance method which can be overrided in child classes
In
src/pybamm/expression_tree/broadcasts.py
I've forced child classes ofBroadcast
to implement_unary_new_copy
because earlier we were usingself.broadcast_domain
in this function in Broadcast class but it does not have any attributeself.broadcast_domain
, this function was only getting called by instance of their child classes which has self.broadcast_domain property.In
tests/unit/test_expression_tree/test_operations/test_copy.py
intest_symbol_create_copy_new_children
test I've added an extra argumentperform_simplifications=False
tocreate_copy
method to ensure 100% coverage of new_instance methods.Related to #3489
Type of change
Please add a line in the relevant section of CHANGELOG.md to document the change (include PR #)
Important checks:
Please confirm the following before marking the PR as ready for review:
nox -s pre-commit
nox -s tests
nox -s doctests