Skip to content

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

Open
wants to merge 22 commits into
base: main
Choose a base branch
from
Open

refactor warnings #3098

wants to merge 22 commits into from

Conversation

d-v-b
Copy link
Contributor

@d-v-b d-v-b commented May 25, 2025

closes #3096

this PR adds zarr-specific subclasses of FutureWarning and DeprecationWarning, 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.

@github-actions github-actions bot added the needs release notes Automatically applied to PRs which haven't added release notes label May 25, 2025
@dstansby
Copy link
Contributor

👍 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.

@d-v-b
Copy link
Contributor Author

d-v-b commented Jun 30, 2025

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.

@d-v-b d-v-b marked this pull request as ready for review June 30, 2025 08:48
@d-v-b d-v-b requested review from jhamman and TomAugspurger June 30, 2025 08:48
@d-v-b d-v-b added this to the 3.0.9 milestone Jun 30, 2025
@d-v-b d-v-b removed this from the 3.0.9 milestone Jun 30, 2025
Copy link

codecov bot commented Jul 11, 2025

Codecov Report

❌ Patch coverage is 14.54545% with 47 lines in your changes missing coverage. Please review.
✅ Project coverage is 60.74%. Comparing base (e410173) to head (713bda9).

Files with missing lines Patch % Lines
src/zarr/api/asynchronous.py 22.22% 14 Missing ⚠️
src/zarr/core/group.py 0.00% 7 Missing ⚠️
src/zarr/core/array.py 16.66% 5 Missing ⚠️
src/zarr/errors.py 0.00% 5 Missing ⚠️
src/zarr/api/synchronous.py 0.00% 2 Missing ⚠️
src/zarr/testing/__init__.py 0.00% 2 Missing ⚠️
src/zarr/_compat.py 0.00% 1 Missing ⚠️
src/zarr/convenience.py 0.00% 1 Missing ⚠️
src/zarr/core/buffer/gpu.py 0.00% 1 Missing ⚠️
src/zarr/core/chunk_grids.py 0.00% 1 Missing ⚠️
... and 8 more
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     
Files with missing lines Coverage Δ
src/zarr/codecs/transpose.py 45.61% <ø> (ø)
src/zarr/_compat.py 0.00% <0.00%> (ø)
src/zarr/convenience.py 0.00% <0.00%> (ø)
src/zarr/core/buffer/gpu.py 41.25% <0.00%> (-0.53%) ⬇️
src/zarr/core/chunk_grids.py 59.81% <0.00%> (-0.57%) ⬇️
src/zarr/core/codec_pipeline.py 70.09% <0.00%> (-1.34%) ⬇️
src/zarr/core/common.py 48.76% <66.66%> (-0.41%) ⬇️
src/zarr/core/dtype/common.py 27.71% <0.00%> (ø)
src/zarr/core/metadata/v2.py 58.13% <50.00%> (-0.34%) ⬇️
src/zarr/creation.py 0.00% <0.00%> (ø)
... and 9 more

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@dstansby dstansby added this to the 3.2.0 milestone Jul 31, 2025
@github-actions github-actions bot removed the needs release notes Automatically applied to PRs which haven't added release notes label Jul 31, 2025
@d-v-b d-v-b requested a review from a team July 31, 2025 21:59
@d-v-b
Copy link
Contributor Author

d-v-b commented Jul 31, 2025

this will allow users who are tired of seeing zarr-specific warnings to suppress them.

@dstansby
Copy link
Contributor

dstansby commented Aug 1, 2025

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?

Copy link
Contributor

@dstansby dstansby left a 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

@d-v-b
Copy link
Contributor Author

d-v-b commented Aug 1, 2025

I removed almost all the ignored warnings from pyproject.toml, at the cost of inserting a bunch of explicit with pytest.warns() statements throughout our tests. This was useful because it revealed how many warnings zarr emits during normal usage. For consolidated metadata in particular I think we need to rethink emitting a warning every time its used. I don't think this feature is typically used by individual users but rather libraries like xarray, in which case the best way to convey the off-spec-ness of consolidated metadata is via documentation.

@d-v-b
Copy link
Contributor Author

d-v-b commented Aug 1, 2025

we should also consider changing our ZipStore implementation to hide the UserWarning emitted whenever a key is modified.

@TomAugspurger
Copy link
Contributor

removed almost all the ignored warnings from pyproject.toml, at the cost of inserting a bunch of explicit with pytest.warns() statements throughout our tests

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.

@d-v-b
Copy link
Contributor Author

d-v-b commented Aug 1, 2025

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

@d-v-b
Copy link
Contributor Author

d-v-b commented Aug 1, 2025

I don't think the coverage report is very useful here. If we discount it, I think this is ready to go

@d-v-b d-v-b requested a review from dstansby August 1, 2025 14:01
@@ -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)
Copy link
Contributor

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.
Copy link
Contributor

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
Copy link
Contributor

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)),),
],
)
Copy link
Contributor

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?

Comment on lines +1 to +2
Define Zarr-specific warning classes ``ZarrDeprecationWarning`` and ``ZarrFutureWarning``, that
subclass ``DeprecationWarning`` and ``FutureWarning``, respectively.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

improve control over warnings
3 participants