This works for now, so I will not press to change it. I do not like the stride manipulation as such though. What would be safest may be to use xs = np.array([1, 2, 3], dtype='i8') and then multiple slicing as in xs[:0] and xs[::2][:0] (you can assert the strides after that).

Or maybe, just for the x.strides = ... part, do x = xs[::2] instead (it should work) and just assert in case the behaviour ever changes.

What's wrong with changing the strides like this? Numpy isn't going to change semantics such that this would break because it would break too much user code.

I think this way of doing it is easier to read than your suggestion because you can literally read off what the strides of the new xs will be, which is important information for reasoning about how the lexsort function will execute. With your suggestion the strides, which are what you really care about, are only updated in an indirect way.

Actually, yes, we should, and eventually probably will deprecate such usage, because that usage is broken in many ways.

It seems to me that an empty array should rightfully be able to have any strides at all set on it, but maybe this breaks something elsewhere in numpy?

Anyway, I don't really fancy changing this if you aren't going to require it, because I do think it is the clearest presentation of the test.

I suppose the other approach is to use np.lib.stride_tricks.as_strided, but OK. Whenever we do the deprecation we can just fixup the test. Of course it is safe for empty arrays or arrays with a single element, but that is about the only case where it is sane.