Did you run the test on a clean session? Otherwise they are probably suppressed. If you are running them on a clean session, there is a with warnings.catch_warnings missing somewhere in tests that are run earlier :(. Tracking that down is annoying, I am not sure there is a nice way to do it.

The thing to remember with testing warnings is that all warnings must be created with "always" filter active.

EDIT: To be more clear, there may be some other test, which gives the warning, but does not notice there is an extra warning being given. And since the warning is not set to "always", it is ignored afterwards. So there is likely a catch warning context, which does not set the filter for all warnings (the default "once" kills things quickly.

By the way, would it be possible to wrap the whole test suit in an "always" context?

Added a PR that might make that problem go away to some degree. (but you always need to use a warning clean session when testing, and that is difficult to provide! E.g. we had it that running numpy tests a second time would give errors because of this kind of issue)

All right, part of the problem was that the test was being skipped in python2, so it was normal not to see the warning.

If I set raise_warnings in python3, that test does indeed raise, but for a different deprecation that happens before mine. If I run the test manually (by importing it and running it) it correctly shows all the deprecations.

In order to be able to see all the deprecation warnings (and not just the first one in a test) I found I need to also comment out this line, and then run np.test('full'). So that problem is solved too.

I added a test and moved unrelated changes to another PR.

I just got a bit worried about multifield subscription/getitem. You know the wonky "buffer" logic in setitem (and we can fix that), but in general I am a bit worried about losing the non-indexed information, i.e. silently overwriting the garbage part of the VOID dtype.
Now the setitem can be fixed, but in general, is it easy to be sure that no garbage will be written into the unused fields which are used in a different view? I do think multifield assignments should certainly work, but just wanted to caution about this before we do anything. It is quite possible that this is really a no issue (after fixing VOID_setitem).

Just to be clear, this PR should only be merged if we decide to go ahead with multi-field indices returning views (#6053). So really I need to finish that, and we need to decide what the plan is in #6053 before deciding what to do here.

As for avoiding writing garbage to unviewed fields, #6053 is already safe with respect to this. The solution was to prevent use of the 'buffer' logic in VOID_setitem if the dtype has fields, and also in the dtype_transfer path to avoid the "simple copy" case if there are fields (here)

@seberg Will your recent work on warnings help make the tests work consistently?

Yes, rebase on master, and you can be sure to find all affected tests (unless they already explicitly filter the future warnings or so). That was the point of it mostly.

I tried rebasing on master, seems somewhere in a calling function an error check is missing or something, got segfaults when running the test suits (I expected tests failing, but not segfaulting)

Cool ,the warning improvements sound promising! I'll fix this up tonight and look into the segfault.

@ahaldane What is the status of this?

Sorry, I had an unexpected turn of events last week. Updated now.

The segfault is fixed. It was due to a missing check that ret is NULL in array_deepcopy, which is only getting triggered now since a FutureWarning is raised.

I added extra wrappers to all the tests the deprecation will affect. The new warning improvements make it very easy to see what tests need to change! Very nice.

Also, originally I thought we would be making both np.diagonal and multifield-indexing return a view, but it's not so clear for np.diagonal. I've removed reference to diagonal from the warnings for now. Previous discussions about it trailed off inconclusively, see #5407 #5409 and the mailing list discussion linked there.

Looks like some more tests need ah fixin'.

Hmm, the remaining error may be fixed by #8066. @gfyoung Thoughts?

@charris : Not sure how my PR will address this failure. My patch is addressing the DEBUG=1 machine.

@gfyoung Well, the simple fix for debug introduced the problem with wheels, so I'm thinking the no-cache-dir may have an impact. Guess @seberg should take a look at this also.

@charris : Hmmm...I guess along the trend of unusual build errors I guess that could be relevant.

Oki, seems like you figured out the "ignore" thing. Could also use the new suppress_warnings context, but it does not matter much, unless you want to make sure you only filter the one warning type.

I think I got the last error: I was ignoring a warning when I should have been recording it. (certain config flags make the numpy warning suite complain about ignored warnings).

updated to use assert_warns, which is much cleaner looking, and added a release note.

Ready to squash yet?

Squashed.

Also, tweaked the warning to remove the recommended workaround, to replace arr[['f1', 'f3']].view(newtype) by arr[['f1', 'f3']].copy().view(newtype). That actually wouldn't work.

The actual workaround is to define something like

def pack_fields(arr):
    dt = arr.dtype
    packed_dtype = np.dtype(zip((n,dt.fields[n][0]) for n in dt.names))
    return array(arr, dtype=packed_dtype, copy=True)

then do pack_fields(arr[['f1', 'f3']]).view(newtype), but that seemed too long to put in the warning.

Hmm, that is a pretty complicated workaround. Maybe we need a packed method or some such. Not sure what the semantics should be for alignment.

Let's see what complaints we can gin up. Thanks Allan.

Thanks for the reviews, Chuck and Sebastian!