-
-
Notifications
You must be signed in to change notification settings - Fork 26k
Further reduce the number of warnings in testing #11240
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
Further reduce the number of warnings in testing #11240
Conversation
I suppressed |
Suppressing ConvergenceWarning in tests, unless the test requires
convergence (or non-convergence) to be valid, is appropriate.
|
Top 20 warnings classes in python 3.6 (697 warnings in total):
|
Without looking into this in more details, I don't have a good proposal that is guaranteed to work about how to best reduce the warnings. I have to admit that I doubt that adding a |
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.
We should not generally be suppressing DeprecationWarning. We need those DeprecationWarnings to know when we're using something we shouldn't. ConvergenceWarning can be suppressed, under the assumption that we often will run a small number of iterations in testing, and do not care about convergence.
ignoring warnings should be done with care. |
Refer to #11252 as well to complement @jnothman comment #11240 (review) |
I agree. Should I remove the filters on DeprecationWarning and ignore ConvergenceWarning only when it satisfies that assumption, or just close this PR? |
Definitely remove the filters on DeprecationWarning, and see if you can see
reasons for ConvergenceWarning where they're occurring (e.g. max_iter).
I'd be happy to hide some ConvergenceWarnings.
|
+1 for hiding some @ShangwuYao I think we should never hide warnings "en masse" at the module level. See #11252 for more details. |
So we can't blindly ignore |
can I suggest you do the following: run all the tests with a setup fixture
that sets the default warning behaviour to error. then you can see where
each warning occurs (although you won't see warnings subsequent to
warnings). Then if you catalogue where different kinds of warning occur, we
can make these decisions with appropriate information.
|
No. Otherwise what would be the point of raising warnings in the first place? |
I thought they were meant to warn users, not for internal tests? |
I reckon ConvergenceWarning is usually for users also. Deprecation is
definitely something important in tests
|
closing this as much of this has been resolved by #11570 and there are now way too many conflicts. |
Further reduce the number of warnings as suggested in #11151