-
Notifications
You must be signed in to change notification settings - Fork 13
Convert warnings to Python #3680
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: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3680 +/- ##
==========================================
+ Coverage 38.13% 38.38% +0.24%
==========================================
Files 88 89 +1
Lines 22470 22400 -70
==========================================
+ Hits 8570 8598 +28
+ Misses 13900 13802 -98 ☔ View full report in Codecov by Sentry. 🚀 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.
Massive improvement, and would work nicely. Just wondering about using logging
rather than a custom solution.
_warnings: ClassVar[list[ProcessWarning]] = [] | ||
|
||
def __init__(self): | ||
raise NotImplementedError(f"{self.__class__.__name__} cannot be instantiated.") |
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.
Isn't this what an abstract base class decorator is for?
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 think that decorator would only stop you instantiating a class that doesn't fully implement the abstract methods, of which we have none here.
raise NotImplementedError(f"{self.__class__.__name__} cannot be instantiated.") | ||
|
||
@classmethod | ||
def create_warning(cls, msg: str, **diagnostics): |
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.
Would it not make more sense to use logging
's warn()
, with an appropriate handler? This would allow us to use info, warnings and errors in the same way, using custom handlers if we want, as well as being able to change log level as required. I think it's designed for this exact purpose, but maybe there's something I'm missing!
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.
@jonmaddock I think the motivation behind a custom solution is the way model warnings have historically been used in PROCESS:
- We often only care about warnings which occur in the final iteration of PROCESS as it is the solution point. I see logging as the tool we would use when we always want to see a warning whereas this solution discards 'irrelevant' ones.
- I don't think we could get the model warnings output into the .OUT file in the same way if we used a logging solution.
b83ecb0
to
6a6cd6c
Compare
Convert
error_handling.f90
to Python with a warning handler (a singleton class). The warnings are defined in the code rather than a separate json file.