check warnings #724

Closed
josef-pkt opened this Issue Mar 23, 2013 · 15 comments

Projects

None yet

2 participants

@josef-pkt
Member

warnings are by default to warn only once per category. However, if warnings are about convergence failure for example, then we should have "always".

PR #723 I introduced a UserWarning for solve_power, that should always warn (or raise).

I don't think we ever did a systematic check of our other Warnings, if or as far as we have them across the models. (e.g. warnings coming from scipy.optimize ?)

@jseabold
Member

Closed by 4164e54

@jseabold jseabold closed this Apr 29, 2014
@josef-pkt josef-pkt reopened this Apr 29, 2014
@josef-pkt
Member

We need unit test and settings that our warnings get always displayed.

@jseabold
Member

How do we control a user setting that needs to be in .pystartup (or similar) to work reliably?

@jseabold
Member

Is there a workaround for this? If not, we just need to put it in the FAQ.

[~/]                                                                            
[1]: import warnings

[~/]                                                                            
[2]: warnings.warn('foobar', UserWarning)                                       
/usr/local/bin/ipython:1: UserWarning: foobar                                   
  #!/usr/bin/python                                                             

[~/]
[3]: warnings.warn('foobar', UserWarning)

[~/]
[4]: warnings.simplefilter('always')

[~/]
[5]: warnings.warn('foobar', UserWarning)
@jseabold
Member

I guess subclasses are fine. So we just have to set a user's warning filter at import time with every warning class that we might use? Is this desirable? Should it be settable?

@jseabold
Member

AFAICT, to avoid circular imports we'll need to define all the Warnings in the top-level __init__.py and add a simplefilter for our Warnings there.

@jseabold
Member

Or everytime we issue a warning we need a simplefilter right before it.

@jseabold
Member

I suppose something like this would work in sm_exceptions

def issue_warning(msg, warning_class):
    from warnings import simplefilter, warn
    simplefilter("always", warning_class)
    warn(msg, warning_class)
@josef-pkt
Member

I don't think we run into circular import problems since sm_exceptions doesn't import anything.

I think we just set the simplefilter to "always" for our exceptions on initial import.
Users can still change them if they want to.

@josef-pkt
Member

Or everytime we issue a warning we need a simplefilter right before it.

I don't think that's "polite".
Some users, or developers that have packages with statsmodels inside will want to control the warning level.

@jseabold
Member

If we remove the ability to test all of the subpackages with .test() then we avoid the circular import. If not, we don't and can't import our exceptions.

@josef-pkt
Member

What's the circle, I don't see it.

suppose we import sm_exceptions in statsmodels.__init__ and set the simple filter there.
I don't see how this relates to running .test()

@jseabold
Member

The subpackages import our nosetest wrapper in __init__.

@jseabold
Member

I.e., I found these useful in the past but not so much now that I'm mainly running nosetest from the command line. I'd be ok with removing it.

https://github.com/statsmodels/statsmodels/blob/master/statsmodels/discrete/__init__.py

@jseabold
Member

Circle goes through tool and distibutions __init__ only, so I can just
remove those.

@jseabold jseabold added a commit to jseabold/statsmodels that referenced this issue Apr 29, 2014
@jseabold jseabold ENH: Always issue our warnings. Closes #724. 466b616
@jseabold jseabold added a commit to jseabold/statsmodels that referenced this issue Sep 23, 2014
@jseabold jseabold ENH: Always issue our warnings. Closes #724. 84bab35
@jseabold jseabold added a commit to jseabold/statsmodels that referenced this issue Sep 24, 2014
@jseabold jseabold ENH: Always issue our warnings. Closes #724. 8f2b6cc
@jseabold jseabold added a commit to jseabold/statsmodels that referenced this issue Sep 26, 2014
@jseabold jseabold ENH: Always issue our warnings. Closes #724. cb752e1
@jseabold jseabold closed this in 36928f0 Sep 26, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment