-
-
Notifications
You must be signed in to change notification settings - Fork 350
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
base: main
Are you sure you want to change the base?
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 60.72% 60.74% +0.02%
==========================================
Files 78 78
Lines 9408 9426 +18
==========================================
+ Hits 5713 5726 +13
- Misses 3695 3700 +5
🚀 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 |
@@ -27,6 +27,8 @@ In Python, the consolidated metadata is available on the ``.consolidated_metadat | |||
attribute of the ``GroupMetadata`` object. | |||
|
|||
>>> import zarr | |||
>>> import warnings | |||
>>> warnings.filterwarnings("ignore", category=UserWarning) |
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.
Is it possible to remove these new lines, and instead include the warnings in the docstest output? Instead of hiding the warnings, it would be nice to be honest about them 😄
|
||
class ZarrFutureWarning(FutureWarning): | ||
""" | ||
A warning raised to indicate when a construct will change semantically in the future. |
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.
What does "construct will change semantically" mean (certainly I don't know!)? Can this be rewritten in less jargon-y language?
|
||
class ZarrDeprecationWarning(DeprecationWarning): | ||
""" | ||
A warning raised to indicate that a construct will be removed in a future release. |
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.
A warning raised to indicate that a construct will be removed in a future release. | |
A warning raised to indicate that a feature will be removed in a future release. |
|
||
class ZarrRuntimeWarning(RuntimeWarning): | ||
""" | ||
A warning for dubious runtime behavior. |
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.
What's the difference between a runtime warning and a user warning? It's not clear to me from these descriptions how to choose between them when introducing a new warning.
(BytesCodec(), TransposeCodec(order=order_from_dim("F", 2))), | ||
(TransposeCodec(order=order_from_dim("F", 2)),), | ||
], | ||
) |
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 the change in paramterization here? Could the store parameterization go back as well as the new codec paraetrization?
Define Zarr-specific warning classes ``ZarrDeprecationWarning`` and ``ZarrFutureWarning``, that | ||
subclass ``DeprecationWarning`` and ``FutureWarning``, respectively. |
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.
Define Zarr-specific warning classes ``ZarrDeprecationWarning`` and ``ZarrFutureWarning``, that | |
subclass ``DeprecationWarning`` and ``FutureWarning``, respectively. | |
Define Zarr-specific warning classes `ZarrDeprecationWarning` and `ZarrFutureWarning`, that | |
subclass `DeprecationWarning` and `FutureWarning`, respectively. |
Because these are in the API docs, use single quotes to link to them.
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.