Hide AstroPy deprecation warnings for clobber - Fix #327 - #328

I claim that the test failures are nothing to do with the astropy warning change, but it's not clear to me what is causing them - e.g. see

https://travis-ci.org/sherpa/sherpa/jobs/188548392#L2114
https://travis-ci.org/sherpa/sherpa/jobs/188548388#L2230

Is there some other change somewhere that is causing this (perhaps in py.test and family; possibly related to #240)

There is some discussion in astropy/astropy#5644 of backing out this deprecation in astropy 1.3.1. It is causing more pain than expected.

Ta for the info, @taldcroft . Unless we "blacklist" astropy 1.3.0, I think we will still need to deal with the warning messages [*].

[*] which is not hard; the more-annoying part is having to deal with a change in the API, but that wasn't part of this PR anyway []
[] just want to make it clear that I am not complaining about AstroPy changing the API here

Aha. Some of the tests in sherpa/astro/io/tests/test_io.py explicitly check for no warnings (i.e. outside of the general warning handling done by conftest.py). So, we can

1. just remove the warning handling in these tests (test_warnings_are_gone_arrays/pha) and let the generic warning handler handle this
2. explicitly drop AstroPy deprecation warnings from the list in the tests.

I think I prefer 2, as 1 is actually a change in behavior, from ensuring there's no warnings to just ignoring any warnings. Are there any other options?

So I implemented option 2, which seems to work.

If this looks good I'll rebase it so there's only one commit.

An alternative to this would be to make the travis builds skip this version of AstroPy (1.3.0), but that only helps the Travis build. Users would still hit the problem.

@DougBurke the result is paradoxical. The test was added in #116 to make sure #27 was fixed, and the bug was indeed that some AstropyDeprecationWarnings were issued. With this PR that test does not make sense anymore. We could just as well remove the test. This might probably be fine, since we now have a proper mechanism for catching warnings. We just need to make sure we are still testing save_data. If we are not, maybe we can change the test in some way that makes sense, removing the check for warnings, which will be caught (if any) upstream.

Would you agree with this plan?

@olaurino - as I see it there are two approaches to the warning messages:

a) ignore them
b) ensure they never happen

and I don't think that there's always going to be a single approach that works. I am actually a bit concerned about the way we generally do a in our tests, as I think it could lead to not realizing we've used deprecated or problematic code, but I am not convinced there's a simple solution to this concern, and it is also larger in scope than this PR!

Getting back to this PR: I think I would be happy in removing the explicit checks for warnings in the test_warnings_are_gone_arrays/pha routines, but don't have the time just now to properly dig into this (i.e. check to see whether we have other tests of the save_data routine so we can drop these two tests). So I leave any further changes in this PR to you.

As far as your item a) goes, I agree that ignoring a warning should in most cases be temporary, and we should try and remove the offending code if possible. As you said, that goes beyond this PR, which is ignoring warnings anyway. If Tom hadn't mentioned there is a good chance the change is going to be reverted back in astropy my review would have been different. Thanks for your input.

Closing this PR in favor of #330.