You can clone with
HTTPS or Subversion.
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.
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.
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?
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.
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.
Perhaps you should add a milestone for "probably never" and assign this issue to it :)
@eteq On the Trac project we called that "2.0".
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?
@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.
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.
Although I'd forgotten about the astropy.show_deprecation_warnings() idea. I just added something similar to that to PyFITS...