Skip to content
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

better warning filter for assert_* #6212

Merged
merged 7 commits into from
Sep 5, 2022

Conversation

mathause
Copy link
Collaborator

In #4864 I added a a decorator for the xarray.testing.assert_* functions to ensure warnings that were to errors (pytest.mark.filterwarnings("error")) do not error in assert_* (see #4760 (comment)). As a solution I added

warnings.simplefilter("always")

However, this is sub-optimal because this now removes all ignore filters! As dask stuff only gets evaluated in assert_* filters like warnings.filterwarnings("ignore", "Mean of empty slice") don't work for dask arrays!

I thought of setting

warnings.simplefilter("ignore")

but this could suppress warnings we want to keep.

So now I remove all "error" warning filters and keep the rest. Note that the original filters get restored after with warnings.catch_warnings():. ().


I am not sure I expressed myself very clearly... let me know and I can try again. @keewis you had a look at #4864 maybe you can review this PR as well?

@@ -29,7 +29,8 @@ def wrapper(*args, **kwargs):
__tracebackhide__ = True

with warnings.catch_warnings():
warnings.simplefilter("always")
# only remove filters that would "error"
warnings.filters = [f for f in warnings.filters if f[0] != "error"]
Copy link
Collaborator

Choose a reason for hiding this comment

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

can we rely on warnings.filters? As far as I can tell, that's semi-public at best: the library is very consistent on using _ as a prefix for truly private attributes, but it also doesn't document filters or list it in __all__. However, the standard library doesn't change very often, so I guess it's not too risky...

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, I am not sure either. But I found no "public" way to unset a specific filter. I think even if it breaks at one point it should mainly affect downstream libraries and not users.

The alternatives are

  • always warn
  • never warn
  • remove the decorator

I would prefer the "result" of what I propose here but I also understand if you deem it too dangerous. I had a quick look at the python issues but found nothing in this direction.

Copy link
Collaborator

@keewis keewis Feb 3, 2022

Choose a reason for hiding this comment

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

warnings will only change on upgrade to a new version of python, which involves some manual work, anyways (and testing is usually blocked by numba for a few months).

I guess this means it should be safe to use? @pydata/xarray, what do you think?

Edit: if filters was renamed to something else we would get a AttributeError, but that should be fairly easy to handle

Edit2: to be extra safe we could also ask the python core devs for clarification

@mathause
Copy link
Collaborator Author

mathause commented Sep 5, 2022

Ok merging this. I think we got some to fix it if this ever causes trouble for a future version of python.

cc @headtr1ck

@mathause mathause merged commit a6a6ac0 into pydata:main Sep 5, 2022
@mathause mathause deleted the better_warning_filter branch September 5, 2022 07:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants