Even though we do not have it as a test dependency, it may still make sense to add a test for it (e.g. add a pytorch fixture). There are some plans to run a weekly test with "all" possible dependencies, although not implemented yet.

I wouldn't want to add a mock test here. That'd be rather self-fulfilling, and we would not have added such a test if we had written that part of the code from scratch.

The only thing, I could imagine would be a real pytorch test with torch = pytest.import_or_skip('torch'). Such a test would currently be inactive, but would be picked up if we add a weekly all-dependencies test. Not sure if it's worth though.

I wouldn't want to add a mock test here. That'd be rather self-fulfilling, and we would not have added such a test if we had written that part of the code from scratch.

The point of such tests is to not break again in a refactor. All the dances around the array conversion are delicate, and documenting behaviour with tests is idea.

I'm not able to come up with a suitable mock object. np.isnan() can take non-arrrays as input. In my naive view it should do something like asarray()/asanyarray() internally, which seems the same as what np.array() is doing. So TBH, I don't really understand, how there can be objects o, that pass np.isnan(np.array(o)), but fail np.isnan(o). pytorch shows that they exist, but that's beyond my craft and I don't have the ambition to dig into this world for a test here. Feel free to push one if you understand the numpy machinery here.

Rebased to fix CI.

I could go either way on the backport.