Repository: numpy/numpy

Issue:
1.11.0 b2: the np.ma view warning is very noisy
The b2 issues a `FutureWarning` that causes some downstream package tests to fail. The tests are usually like

```
with catch_warnings() as ws:
    do_something()
assert len(ws) == 0
```

and numpy emits a `FutureWarning('Currently, slicing will try to return a view of the data, but will return a copy of the mask. In the future, it will try to return both as views.',)`. This happens in astrofrog/wcsaxes#187 and astropy/astropy#4549



Discussion:
First of all, thanks for reporting :-)

Now about the error: hmm. So, my first impulse is to say that this test is wrong -- the whole point of deprecation/future warnings is that they give a grace period where old astropy will continue to work with new numpy. If you go ahead and convert these into hard errors, then it makes the whole ecosystem more brittle, because we lose that ability to gracefully warn people about things. What we do for numpy itself is have a switch where we turn all deprecation warnings into errors when testing development releases so that we notice, but then disable them for actual releases so that users aren't confused by e.g. a new version of Python adding a new deprecation warning and it causing old numpy releases to stop passing their test suite. ([code here](https://github.com/numpy/numpy/blob/master/numpy/testing/nosetester.py#L511), though for you the details would probably be different unless you're using numpy's `NoseTester` class).

One thing we might be able to do is make that warning more narrowly focused so that it doesn't trigger as often -- it doesn't really fix the underlying problem, but it might help :-). @seberg: I think I saw a PR go by to make the masked array slicing warning more precise (i.e. trigger on writes, not on views) -- what happened with that? Is it in master? Is it already included in 1.11.0b2?

The other option (besides "do nothing") would be to back out the change because it's genuinely too disruptive. Do you have any thoughts on that?

No, I just suggested it might be possible, I had a start, but I don't think it was quite correct (but maybe it was correct _enough_, in that issuing that damn warning too few times would at the moment probably still be better). Frankly this warning is issued so incredibly imprecise and often, that I am not sure that it would not be better to just let it go.

One half solution is: issue it only when `data` is actually returned as a view (may_share_memory), and _not_ bother about the fact that actually "setitem" is the actual dangerous operations. Possibility 2 (the precise one): When data is returned as a view, set the special "warning on write" flag to both arrays. Would still give loads of false positives, but at least not a gazillion that even trigger when all you do is even item setting.

I don't remember setting this warning go in, I think the change as such is good, but my gut feeling is if we don't make it more specific we should revert it for 1.11 maybe.

Now about the testing :). I have a pretty big PR open which tries to address that issue a bit (gh-7099). It creates a `suppress_warnings` context manager, with which you can do:

```
with suppress_warnings() as sup:
    sup.filter(FutureWarning, message="Currently, slicing will try to return a view of the data")
    sup.record(UserWarning)  # Count UserWarnings *only*
    do_something()
    assert_(len(sup.log) == 0)
```

Note that doing an "ignore" filter, while it "works" can also backfire quite badly (mostly on Python <3.4) if you want to test this warning being given elsewhere.

PS: Why do you have tests that check that zero warnings are given? In dev tests, we the tests up to error on warnings. They are already raised (or printed), so if you they succeed they can't have given a warning?!

@seberg: I don't think astropy or wcsaxes are using the same testing machinery as us :-) (And I doubt they will want to depend on `suppress_warnings` for another year or so :-/)

maybe @astrofrog could comment here...

@jakirkham: so that's one vote up above for possibly reverting #7020. What do you think?

Hehe, right, that was a bit silly, I have been too annoyed by warning testing recently ;). The context manager might still be interesting, since you can steal it. It proofs the point nicely that we should try to make warning assertions as specific as possible :/.

> So, my first impulse is to say that this test is wrong...

I agree with @njsmith on this point and his rationale.

> One thing we might be able to do is make that warning more narrowly focused so that it doesn't trigger as often...

I am not against doing this. Sorry the warning is driving people nuts. Was more concerned with avoiding false negatives as I got the strong impression that people were terrified of breaking behavior in masked array so I thought a loud warning would get people to take a hard look at their code and make sure it was doing what they expected. But I will admit it may be too loud. Happy to work with you, @seberg, to turn down the volume. :)

> The other option (besides "do nothing") would be to back out the change because it's genuinely too disruptive.

On this point, I am sorry, but I must put my foot down. I think this is a -1 from me. There is already a consensus that the current behavior of masked array is broken and we have a way that people seem to agree on to fix it. Leaving the code broken I don't think is ok. Changing the warning, the volume, the wording, etc. of the warning I am ok with, but I do believe people should be warned and I do believe we should fix this behavior.

To be clear, I am not opposed to the change, but if we are creating serious problems for downstream, we have to back off. Maybe that is the case maybe not.

The reason why I mentioned simply reverting it is because I am not sure how fast or easy it is to make it silent (enough). For all I see this was put in just before the release, and if the only non-messy solution or clear solution is to revert it and figure out something better for the _next_ release, then that sounds fine to me.
I have been waiting for probably 2-3 years for finally shipping relaxed strides, and guess what, in 1.11 we had to push that off for another two releases....

Frankly, if the Astropy folks are happy to live with the test failures, or we can find something that makes them happy enough (i.e. at least less warnings) then that is the way to go.

I am sure Astropy _wants_ the ultimate change, so my opinion:

Do whatever downstream prefers us to do, at least for the 1.11 release!

> 1.11 we had to push that off for another two releases

1.10. IIRC. I'm planning on bringing relaxed stride checking as default back in 1.12. The only real problem that turned up was taking views of multidimensional Fortran ordered arrays that became C ordered as well.

Simce apparently I am daft Can someone please give me an example when the mask is not _already_ a view into the other mask?!

Honestly, the mask is **always** not a view. Though that surprised me too, which is why I thought to make the change. It even shows up in the documentation, which @mhvk  pointed out to me.

> When accessing a slice, the output is a masked array whose data attribute is a view of the original data, and whose mask is either nomask (if there was no invalid entries in the original array) or a copy of the corresponding slice of the original mask. The copy is required to avoid propagation of any modification of the mask to the original.

( http://docs.scipy.org/doc/numpy/reference/maskedarray.generic.html#indexing-and-slicing )

That last line really gets me. If I were to use a normal array and take a view via slice or some other means, and assign some data value that affects the original array. However, if I mask some values (the same way as `nan` might be assigned to a normal array), then that won't affect the original array. Why this would be intentional is honestly still baffling to me.

How is this always, btw. gives the same even on 1.8.2:

```
In [12]: arr = np.ma.masked_less_equal(np.linspace(0, 1, 100), 0.5)

In [13]: arrb = arr[::2]

In [14]: np.may_share_memory(arrb._mask, arr._mask)
Out[14]: True
```

Ah, there is a sharedmask flag, which gets set so that the child will not propagate to the parent on getitem (and maybe other things). But if that is the case, making the warning specific should not be hard at all.

In fact all of that voodoo already happens in a specific function `def unshare_mask(self):`, so it is likely OK, to just put the warning there, though should check it more closely.

I thought you were going to suggest that we simply check to see when `sharedmask` is `True` and emit a warning then.

Dunno, maybe it is completely wrong, but....

Sorry, I have to briefly return to your original point.

> ...if we are creating serious problems for downstream, we have to back off.

If we do discover that changing copies to views does cause problems for people, I am ok with holding that change off as needed. Though we will never know if this causes them problems without getting them to think about it and perhaps getting them to try our proposed fix, which requires people know we are doing this.

However, when it comes to deprecation/future warnings, it seems like the logic that is being proposed is to never deprecate or break functionality by warnings because people may depend on when, where, and how many warnings we issue. This doesn't feel correct to me and it doesn't sound like I am alone on this. Personally, I would rather help downstream come up with a better way to test their internal warnings (what appears to be the point of these tests).

<br>
My feelings on the above portion are independent from being willing to work on improvements to the warning. Just bare in mind that we are planning to make a badly needed but substantial change to the behavior of the masked array; so, we will end up getting a fair number of warnings even if we get down to the necessary number of warnings.

@jakirkham - sorry to have been silent on the astropy side, but I agree that here astropy should be sure not to trip over the warning in the first place -- we need to rewrite the test.

Sorry that I am a bit annoyed at this whole thing in general, please try to ignore it ;).

Anyway, I did not say or at least mean that, I said we may want to delay. Just because the warnings are given a lot and downstream might ask for it. I am talking about one release, that is all. And for a PR that was opened something like two weeks before forking of the release branch, it frankly does not seem like a big deal to me. Some things need a bit time.

Maybe we can use a bit time to figure out how to make the warnings to be actually useful, since right now they are given so much, that it is not even worth to start thinking whether a test failing due to that warning might indicate a future error. Or did you actually look at all the tests that you added a warning filter for to see if it was actually correct to ignore it there?

Taking a week or two to make it better is not nicely compatible with including it into 1.11, less so if the fix might be complicated.

Btw. it might seem overstating, but numpy itself has 217+ test failures if you would just add the warning. The fact that you got off with ignoring it a few times or so, is just that testing these warnings is currently rather broken. Of course almost all of them are in the same ma test file, but still.

> Sorry that I am a bit annoyed at this whole thing in general, please try to ignore it ;).

Sorry you are annoyed. It was never my intent to annoy anyone.

My only intent has been to get a 1 year old bug fix into NumPy. Though this bug has presumably been there for the entire life of NumPy.

Honestly it is getting to the point where I question how much trouble it is worth. Personally, this fix doesn't even affect anything I do at present. It was something I encountered in some work I did a year ago for another project and I felt I should try to help rectify what I saw as a problem. So I am only championing it at this point because I think it is the right behavior and others share this belief.

> And for a PR that was opened something like two weeks before forking of the release branch, it frankly does not seem like a big deal to me. Some things need a bit time.

Again the bug fix has been proposed for 1 year and has been pushed off for a few releases. In fact, we have been discussing for the last half year how best to handle the fact that this change is a breaking change.

> I am talking about one release, that is all.

So only one additional release of bad behavior while we try to tweak the warning, which will be removed as soon as the bad behavior gets corrected. Not to mention, this is a warning that is regarding assignment. It will still be loads of places in the best case. Plus, I am not convinced that we won't just create a bunch of false negatives (or worse introduce some nefarious side effects) that will allow people to quietly continue bad habits (or get surprised by strange bugs). Then when the bug fix gets added in some beta they will protest the bug fix too late for us to do anything, but rip it out and drag this out even longer. What can we say if they didn't see the warning after all? Finally, in some cases, a big warning was explicitly requested so there will be more wrangling about whether the new warning is big enough. Is this really what we want to pursue?

Honestly, I have no interest in supporting this patch for years without any progress. Also, I don't think it is fair to expect a relatively minor contributor to do so. Personally, I think it is time to see some actionables cleared here. Deprecating the current behavior in 1.11.0 is the price of me staying engaged at this point. I don't say this to be rude. Just I have a limited amount of time I can devote to this. Also, on a more personal note, I have seen this bugfix on the chopping block and then removed right before every release since it was proposed simply because it is a breaking change with desirable behavior. I don't have the heart to keep watching this.

> Or did you actually look at all the tests that you added a warning filter for to see if it was actually correct to ignore it there?

Not sure I like what is being implied here. Please try to be respectful.

FWIW, I added those tests in my first ever PR to NumPy. :) They are in-place tests for mathematical operations on masked arrays and I find it reassuring that the warning shows up there. It means it is hitting one of its targets.

> Btw. it might seem overstating, but numpy itself has 217+ test failures if you would just add the warning.

So, not sure how you are computing this. Are you turning all these warnings to errors?

In any event, yes, we are proposing that we change how assignment works with masked arrays. No matter how the warning is tweaked, I don't see this not still being quite loud. Also, the plan is for these warnings to be removed and the fix added.

> Maybe we can use a bit time to figure out how to make the warnings to be actually useful

While I have seen the occasional suggestion of how to turn the volume down on this warning over the last couple weeks, it remains unclear to me what concrete suggestion there is to pursue here. Though I think I saw one attempt, it was ultimately abandoned. Also, it remains unclear to me that we won't simply have a bunch of false negatives (or something else) that would be far worse.

> Taking a week or two to make it better is not nicely compatible with including it into 1.11, less so if the fix might be complicated.

I tried to propose the simplest solution because it is straightforward and allows people to know what is going on. It is also easy to be sure that people will be aware of the change. IMHO complicated solutions tend to be ones that have problems. It is not clear to me that after a couple of weeks of working on some slick solution for the warning that we aren't hiding it in some way or introducing some tricky subtle behavior. Not to mention, the warning will likely remain very loud; after all, it is a warning about assignments.

In short, I am increasingly feeling that changing the warning is a bad idea.

OK, just wanted to say why I think a temporary revert is on the table. Lets see if anyone complains....

Yes, the 217 is turning them to errors/printing in release, which is the right thing to do IMO, but (still) broken in master.

Missing it in some obscure cases does not seem completely bad to me. Printing a warning even for `masked_arr[0] = True` is likely to just make you read it once and silence/ignore it after that, the warning will not help you find the obscure case in any case.

That is your prerogative. My primary concern is that this puts me in a position where it will require significantly more effort on my part and the whole effort still may be scrapped at any point. My secondary concern is that it (the warning changes) either won't make much of a difference or will make things worse.

@jakirkham, OK, I still have one question for you though. What would the next step be in a release or two, what changes do we have to do to achieve the final correct result?

Sure, the changes to NumPy appear to be pretty minimal ( https://github.com/numpy/numpy/pull/5580 ). 

So why not put the warning into that removed branch? Can you think of any other way an operation might result in a different thing in the future?

OK, so if you don't mind, can I ask you to move the FutureWarning into all of those branches that will get changed and might cause different behaviour? Without a code change, there is no chance that a FutureWarning is necessary (Edited: meaning that only code paths that will change need to cause warnings).

My quick try on numpy gives for the numpy test a tuning down of about a factor of 5, which would mean a higher specificity and much less annoying.

It also means it provides far more information for downstream. And gives you the possibility to make the warning an error and track down possible problems. At the current state this won't work, since before most real problems could occur, it seems most likely there is already a spurious false positive.

> meaning that only code paths that will change need to cause warnings

FWIW, I think what you are proposing sounds reasonable. However, this only addresses my secondary concern.
<br>

So, I would like to re-raise my primary concern. Namely expending more potentially wasted effort on this bugfix. The only way I would agree to do this is _if_ the following conditions are met.
1. The warning changes are included in 1.11.0.
2. Everyone here can agree the change you are proposing is satisfactory.

Not meeting 1 means dragging this out for at least another release, if not more, and increasing the amount of time I have to spend maintaining this patch through various merge conflicts, extended discussion, release preparations, etc. Not meeting 2 means I will have to spend extra time rewriting and explaining this code because we did not have an agreement on its specifications. Admittedly not meeting 2 will make 1 hard if not impossible. Hopefully that gives you some insight into my concerns here.

If these constraints are agreeable and can be demonstrated as met, I will make the proposed change. If it is decided that these constraints cannot be met and the existing plan of action does not work (current future warning in 1.11.0), then I would politely suggest finding someone who is willing to maintain this patch in the future (assuming it is still desirable).

I am sorry to set such hard constraints here, but there is a limit to what I am still willing to do here. If that limit is not sufficient for completing this, then I would like to determine that before reaching it and making anyone (more) frustrated.

This thing is starting to get out of hand, could everyone involved please tone it down.

My own feeling is that specificity is good, the more the better, but that the original problem was not that bad in the first place and that the proposed future change is how folks expect masked array slices to behave.

Sounds fine to me

Anyway, I ow you an apology. On top of that I admit I did hijack this thread probably vastly overestimating the impact of the warnings on downstream, because I was already convinced that it would be better to try to limit the warning more. We all agree on the proposed future change for sure.

@jakirkham: I totally understand your frustration (I've been in exactly your position before with other projects :-/), and thanks for being clear about what you are and aren't able to do.

It's an unfortunate reality that we're all volunteers here, trying to manage a project that's used _very_ widely. This means that on the one hand we have to be pretty careful, and on the other that we sometimes fail to give things the attention that they need, at least in a timely manner :-/. So it does happen sometimes that the full consequences of a change aren't realized until later, and then we still have to try to figure out what's best for the millions of users who will be affected, even if this means making difficult choices and occasionally missing out on a good change (at least temporarily) because we don't have the interest and resources to do it right :-(.

I'm not sure what the right thing to do about this particular warning is, but I do have a few concerns:

1) Because it's so non-specific (basically goes off for any code that uses masked arrays at all), it risks creating a kind of "boy who cried wolf" effect -- if we spit out tons of false positives, then people get annoyed and stop paying attention to our warnings in general, and impatient with other deprecations (including ones that might be as or more important), plus it's not very helpful for tracking down real errors.

2) There's no way to fix code to shut it up -- you can't just like, rewrite your code to not use indexing :-). But this means that this is a warning that everyone will just end up constantly showing their users for the next 1-2 years, even the projects that are really good and on top of things, and the code that's been fixed and the code that hasn't been fixed will behave identically. This seems really unfriendly to our downstreams :-(

Currently, the matplotlib test suite triggers the warning 317 times, and the statsmodels test suite triggers the warning 102 times. (Well... it's actually worse than that, because that's running the statsmodels test suite without matplotlib installed, so it skips all the plotting tests; if you have matplotlib installed then statsmodels's usage of matplotlib triggers more warnings. The important thing here is that the warnings aren't just happening in special np.ma-testing-code -- matplotlib actually creates and uses np.ma arrays internaelly, so matplotlib users who aren't using np.ma can still get swamped with this message. In fact the statsmodels folks are a bit confused since as of right now they think they aren't using np.ma themselves at all, and they can't figure out where these warnings are coming from if it's not matplotlib.)

I guess another factor to keep in mind also is that it's possible that over the time period it would take to make this change, it might make more sense to deprecate np.ma entirely in favor of a better from-scratch rewrite. (I remember @charris was making noises in this direction, and it would fit in with some of our larger plans for making third-party array-ish classes work better.) This doesn't mean we shouldn't try to improve np.ma, but it might affect how much work people are willing to put into doing so.

My personal inclination given all of the above: if we can make the warning trigger conditions specific enough that carefully written code can avoid it entirely, and also make it silent for now (so a three step deprecation cycle: silent warning to give diligent projects like matplotlib time to clean things up -> visible warning to catch the laggards -> finally make the actual change), then it might make sense for 1.11, both otherwise we may need to pull back and reconsider it later.

Just a comment on how the astropy/wcsaxes tests were written originally: I don't think there is anything wrong with them as such, but we can just be more specific in what kinds of warnings we are trying to catch. I don't think we need any change on the Numpy side to fix the tests.

However, in general I do think it would be a good idea to make the warning more targeted if possible, to the specific cases where behavior will actually change the results, if that is at all possible.

No, you are right, the tests are not that bad, though being more specific is better, since then you can print new upstream warnings without making it appear like problems to your own downstream users.

Doing it is tricky though in any case :(. `catch_warnings` catches everything, and "ignore" somewhat breaks testing, at least on Python 2 (since we all test python 3 as well, I am not entirely sure it is _that_ bad).... For numpy I started with gh-7099 to address the problem, but if someone has a nicer idea :)...

Just to mention it here, see gh-7187 for my take on tuning it down, lets see if it is enough


Resolving patch:
diff --git a/numpy/ma/core.py b/numpy/ma/core.py
--- a/numpy/ma/core.py
+++ b/numpy/ma/core.py
@@ -82,6 +82,9 @@
 MaskType = np.bool_
 nomask = MaskType(0)
 
+class MaskedArrayFutureWarning(FutureWarning):
+    pass
+
 
 def doc_note(initialdoc, note):
     """
@@ -3105,13 +3108,6 @@ def __getitem__(self, indx):
         Return the item described by i, as a masked array.
 
         """
-        # 2016.01.15 -- v1.11.0
-        warnings.warn(
-            "Currently, slicing will try to return a view of the data," +
-            " but will return a copy of the mask. In the future, it will try" +
-            " to return both as views.",
-            FutureWarning
-        )
 
         dout = self.data[indx]
         # We could directly use ndarray.__getitem__ on self.
@@ -3184,13 +3180,17 @@ def __setitem__(self, indx, value):
 
         """
         # 2016.01.15 -- v1.11.0
-        warnings.warn(
-           "Currently, slicing will try to return a view of the data," +
-           " but will return a copy of the mask. In the future, it will try" +
-           " to return both as views. This means that using `__setitem__`" +
-           " will propagate values back through all masks that are present.",
-           FutureWarning
-        )
+        self._oldsharedmask = getattr(self, "_oldsharedmask", False)
+        self._oldsharedmask = self._oldsharedmask or self._sharedmask
+        if (self._mask is not nomask) and self._oldsharedmask:
+            warnings.warn(
+                "Currently, slicing will try to return a view of the data, but"
+                " will return a copy of the mask. In the future, it will try"
+                " to  return both as views. This means that using"
+                " `__setitem__` will propagate values back through all masks"
+                " that are present.",
+                MaskedArrayFutureWarning
+            )
 
         if self is masked:
             raise MaskError('Cannot alter the masked element.')
@@ -3234,7 +3234,9 @@ def __setitem__(self, indx, value):
         elif not self._hardmask:
             # Unshare the mask if necessary to avoid propagation
             if not self._isfield:
+                _oldsharedmask = self._oldsharedmask
                 self.unshare_mask()
+                self._oldsharedmask = _oldsharedmask
                 _mask = self._mask
             # Set the data, then the mask
             _data[indx] = dval
@@ -3440,6 +3442,7 @@ def unshare_mask(self):
         if self._sharedmask:
             self._mask = self._mask.copy()
             self._sharedmask = False
+            self._oldsharedmask = False
         return self
 
     sharedmask = property(fget=lambda self: self._sharedmask,


Test patch:
diff --git a/numpy/ma/tests/test_core.py b/numpy/ma/tests/test_core.py
--- a/numpy/ma/tests/test_core.py
+++ b/numpy/ma/tests/test_core.py
@@ -2223,7 +2223,6 @@ def test_inplace_addition_scalar_type(self):
         for t in self.othertypes:
             with warnings.catch_warnings(record=True) as w:
                 warnings.filterwarnings("always")
-                warnings.simplefilter('ignore', FutureWarning)
                 (x, y, xm) = (_.astype(t) for _ in self.uint8data)
                 xm[2] = masked
                 x += t(1)
@@ -2238,7 +2237,6 @@ def test_inplace_addition_array_type(self):
         for t in self.othertypes:
             with warnings.catch_warnings(record=True) as w:
                 warnings.filterwarnings("always")
-                warnings.simplefilter('ignore', FutureWarning)
                 (x, y, xm) = (_.astype(t) for _ in self.uint8data)
                 m = xm.mask
                 a = arange(10, dtype=t)
@@ -2269,7 +2267,6 @@ def test_inplace_subtraction_array_type(self):
         for t in self.othertypes:
             with warnings.catch_warnings(record=True) as w:
                 warnings.filterwarnings("always")
-                warnings.simplefilter('ignore', FutureWarning)
                 (x, y, xm) = (_.astype(t) for _ in self.uint8data)
                 m = xm.mask
                 a = arange(10, dtype=t)
@@ -2300,7 +2297,6 @@ def test_inplace_multiplication_array_type(self):
         for t in self.othertypes:
             with warnings.catch_warnings(record=True) as w:
                 warnings.filterwarnings("always")
-                warnings.simplefilter('ignore', FutureWarning)
                 (x, y, xm) = (_.astype(t) for _ in self.uint8data)
                 m = xm.mask
                 a = arange(10, dtype=t)
@@ -2318,7 +2314,6 @@ def test_inplace_floor_division_scalar_type(self):
         for t in self.othertypes:
             with warnings.catch_warnings(record=True) as w:
                 warnings.filterwarnings("always")
-                warnings.simplefilter('ignore', FutureWarning)
                 (x, y, xm) = (_.astype(t) for _ in self.uint8data)
                 x = arange(10, dtype=t) * t(2)
                 xm = arange(10, dtype=t) * t(2)
@@ -2335,7 +2330,6 @@ def test_inplace_floor_division_array_type(self):
         for t in self.othertypes:
             with warnings.catch_warnings(record=True) as w:
                 warnings.filterwarnings("always")
-                warnings.simplefilter('ignore', FutureWarning)
                 (x, y, xm) = (_.astype(t) for _ in self.uint8data)
                 m = xm.mask
                 a = arange(10, dtype=t)
@@ -2356,7 +2350,6 @@ def test_inplace_division_scalar_type(self):
         for t in self.othertypes:
             with warnings.catch_warnings(record=True) as w:
                 warnings.filterwarnings("always")
-                warnings.simplefilter('ignore', FutureWarning)
                 (x, y, xm) = (_.astype(t) for _ in self.uint8data)
                 x = arange(10, dtype=t) * t(2)
                 xm = arange(10, dtype=t) * t(2)
@@ -2392,7 +2385,6 @@ def test_inplace_division_array_type(self):
         for t in self.othertypes:
             with warnings.catch_warnings(record=True) as w:
                 warnings.filterwarnings("always")
-                warnings.simplefilter('ignore', FutureWarning)
                 (x, y, xm) = (_.astype(t) for _ in self.uint8data)
                 m = xm.mask
                 a = arange(10, dtype=t)