[FIXED] How to reset warnings completely

Issue

How can I see a warning again without restarting python. Now I see them only once.

Consider this code for example:

import pandas as pd  
pd.Series([1]) / 0

I get

RuntimeWarning: divide by zero encountered in true_divide 

But when I run it again it executes silently.

How can I see the warning again without restarting python?

---

I have tried to do

del __warningregistry__

but that doesn't help.

Seems like only some types of warnings are stored there. For example if I do:

def f():   
    X = pd.DataFrame(dict(a=[1,2,3],b=[4,5,6]))
    Y = X.iloc[:2]
    Y['c'] = 8

then this will raise warning only first time when f() is called. However, now when if do del __warningregistry__ I can see the warning again.

---

What is the difference between first and second warning? Why only the second one is stored in this __warningregistry__? Where is the first one stored?

Solution

How can I see the warning again without restarting python?

As long as you do the following at the beginning of your script, you will not need to restart.

import pandas as pd
import numpy as np
import warnings
np.seterr(all='warn')
warnings.simplefilter("always")

At this point every time you attempt to divide by zero, it will display

RuntimeWarning: divide by zero encountered in true_divide 

---

Explanation:

We are setting up a couple warning filters. The first (np.seterr) is telling NumPy how it should handle warnings. I have set it to show warnings on all, but if you are only interested in seeing the Divide by zero warnings, change the parameter from all to divide.

Next we change how we want the warnings module to always display warnings. We do this by setting up a warning filter.

What is the difference between first and second warning? Why only the second one is stored in this __warningregistry__? Where is the first one stored?

This is described in the bug report reporting this issue:

If you didn't raise the warning before using the simple filter, this would have worked. The undesired behavior is because of __warningsregistry__. It is set the first time the warning is emitted. When the second warning comes through, the filter isn't even looked at. I think the best way to fix this is to invalidate __warningsregistry__ when a filter is used. It would probably be best to store warnings data in a global then instead of on the module, so it is easy to invalidate.

Incidentally, the bug has been closed as fixed for versions 3.4 and 3.5.

Answered By - Andy

Answer Checked By - Gilberto Lyons (PHPFixing Admin)