Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Improve visibility of deprecation warnings #570

Closed
embray opened this Issue · 10 comments

5 participants

@embray
Collaborator

Recent discussions in matplotlib (matplotlib/matplotlib#1535) and also in Numpy have brought up the fact that DeprecationWarnings, while annoying users on Python 2.6, fall silent, sometimes dangerously, for users of newer Python versions that silence deprecation warnings by default.

We should consider how those projects dealt with this issue and probably do something similar.

@mdboom
Collaborator

The matplotlib solution was to raise a custom MatplotlibDeprecationWarning which is a subclass of UserWarning rather than use the default DeprecationWarning. It was felt that asking the user to turn on DeprecationWarning was both too cumbersome and results in showing deprecation warnings about Python itself, which the user may not want. It's not an ideal solution, but it's a reasonable compromise.

@embray
Collaborator

Is there a sense of how much we should sympathize with users who don't want to see deprecation warnings and don't know how to disable them?

@astrofrog
Owner

I guess the problem is not so much users who are using the wrong API (they can update) compared to users using packages that rely on Astropy, where they have no control over those packages. In those cases, the deprecation warnings can become annoying. Not sure what the best course of action is though.

@embray
Collaborator

Exactly. I could probably concoct some heuristics based on stack analysis to determine when or when not to issue the warning. I have a few places like that in pyfits where a warning is only issued for using a particular feature if it's not being used directly by pyfits (there was a good reason to do this; I forget why). But that gets pretty hairy when you're starting to involve multiple third-party packages. There's probably no good way.

@eteq
Owner

Perhaps you should add a milestone for "probably never" and assign this issue to it :)

@embray
Collaborator

@eteq On the Trac project we called that "2.0".

@ChrisBeaumont
Collaborator

Hi, I'm visiting from #816

If for no other reason than to stir up the pot: what about a custom warning subclass, and a convenience method like astropy.show_deprecation_warnings(False) that interfaces with warnings.filters appropriately? Then the warnings could be visible by default, yet easily disabled by annoyed users?

@embray
Collaborator

@ChrisBeaumont That sounds reasonable. I'll have to give it a thought. Astropy also has a config infrastructure this could be part of rather than as function.

@embray
Collaborator

This is now implemented by #1871; deprecation warnings will be displayed by default using the AstropyDeprecationWarning class similarly to how this was handled in matplotlib.

@embray embray closed this
@embray
Collaborator

Although I'd forgotten about the astropy.show_deprecation_warnings() idea. I just added something similar to that to PyFITS...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.