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

check warnings #724

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

Comments

Projects
None yet
2 participants
@josef-pkt
Copy link
Member

commented Mar 23, 2013

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

This comment has been minimized.

Copy link
Member

commented Apr 29, 2014

Closed by 4164e54

@jseabold jseabold closed this Apr 29, 2014

@josef-pkt josef-pkt reopened this Apr 29, 2014

@josef-pkt

This comment has been minimized.

Copy link
Member Author

commented Apr 29, 2014

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

@jseabold

This comment has been minimized.

Copy link
Member

commented Apr 29, 2014

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

@jseabold

This comment has been minimized.

Copy link
Member

commented Apr 29, 2014

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

This comment has been minimized.

Copy link
Member

commented Apr 29, 2014

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

This comment has been minimized.

Copy link
Member

commented Apr 29, 2014

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

This comment has been minimized.

Copy link
Member

commented Apr 29, 2014

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

@jseabold

This comment has been minimized.

Copy link
Member

commented Apr 29, 2014

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

This comment has been minimized.

Copy link
Member Author

commented Apr 29, 2014

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

This comment has been minimized.

Copy link
Member Author

commented Apr 29, 2014

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

This comment has been minimized.

Copy link
Member

commented Apr 29, 2014

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

This comment has been minimized.

Copy link
Member Author

commented Apr 29, 2014

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

This comment has been minimized.

Copy link
Member

commented Apr 29, 2014

The subpackages import our nosetest wrapper in __init__.

@jseabold

This comment has been minimized.

Copy link
Member

commented Apr 29, 2014

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

This comment has been minimized.

Copy link
Member

commented Apr 29, 2014

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

jseabold added a commit to jseabold/statsmodels that referenced this issue Apr 29, 2014

jseabold added a commit to jseabold/statsmodels that referenced this issue Sep 23, 2014

jseabold added a commit to jseabold/statsmodels that referenced this issue Sep 24, 2014

jseabold added a commit to jseabold/statsmodels that referenced this issue Sep 26, 2014

@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
You can’t perform that action at this time.