-
-
Notifications
You must be signed in to change notification settings - Fork 352
refactor warnings #3098
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
refactor warnings #3098
Conversation
👍 to having our own zarr warning sub-classes, I think I'm 👎 on having some of our own warning silencing helpers, but depends on what the proposal is I guess. So would be good to have separate PRs for those. |
I amended the PR description to remove the goal of providing top-level functions for users to silence zarr warnings. For now, users can use the built-in warnings library to control warnings. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3098 +/- ##
==========================================
+ Coverage 94.40% 94.54% +0.13%
==========================================
Files 78 78
Lines 9401 9419 +18
==========================================
+ Hits 8875 8905 +30
+ Misses 526 514 -12
🚀 New features to boost your workflow:
|
…into refactor-warnings
this will allow users who are tired of seeing zarr-specific warnings to suppress them. |
I milestoned as 3.2.0, but I guess this isn't breaking (because the new warnings subclass the old warnings), so could go in 3.1.2 instead? |
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.
Code changes look good overall, but:
- Tests need fixing
- I think there's more warnings in the list of our warning filters that should be converted to the new zarr-specific warnings
- The new warning classes shold be included in the API docs
I removed almost all the ignored warnings from pyproject.toml, at the cost of inserting a bunch of explicit |
we should also consider changing our |
Thanks for doing this. I was going to suggest that, but didn't want to assign work to you that's only tangentially related to the PR. I think that being explicit in the tests about where warnings are raised is a good practice. |
consistent with my "test code models user code" theory, excluding every warning individually from the tests has given me a newfound appreciation for all the warnings zarr-python emits on a regular basis |
I don't think the coverage report is very useful here. If we discount it, I think this is ready to go |
Co-authored-by: David Stansby <[email protected]>
Co-authored-by: David Stansby <[email protected]>
Co-authored-by: David Stansby <[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.
One final comment on the release note, otherwise 👍 Once that's fixed, feel free to self-merge
closes #3096
this PR adds zarr-specific subclasses of
FutureWarning
andDeprecationWarning
,so that we can expose routines for silencing future / deprecation warnings specifically emitted by zarr-python.This PR is a draft until I add the silencing routines later in this PR.