Make two_mutual_arrays accept a dtypes strategy as input

[asmeurer]

two_mutual_arrays accepts a list of dtype objects rather than a strategy for generating dtypes. This is somewhat annoying, as everything else uses the dtypes strategies.

A issue with this is that it currently ignores the filtering that is done in the dtype strategies. This makes any test using it fail in pytorch, which doesn't have uint8.

If we can make it accept a dtypes strategy, that would be great. We may just need to have an internal mapping of dtype strategies to promotable dtype strategies. Or maybe we can just draw a dtype then draw another dtype that is promotable compatible with it.

[asmeurer]

Actually it looks like torch fails because it doesn't accept an integer argument to full, only a tuple. If you patch this in hypothesis to pass in a tuple, it fails for other reasons (torch.equal doesn't return an array). I think there is a torch branch somewhere that has better array API support that we should be testing against.

[honno]

So yeah, two_mutual_arrays does already infact filter dtypes. However I realised the underlying mutually_promotable_dtypes() strategy doesn't filter them when max_size>2 (e.g. in some type promotion tests), so that should be fixed in #34.

[asmeurer]

Let's leave this open for making two_mutual_arrays accept a strategy as input. It's something that confuses me almost every time I run into it, so it would be good to change it if at all possible.

[honno]

Hmm, so I can't figure out how to do this nicely. Both the dtype strategies in hypother_helpers.py and in xps.* return generic strategies with seemingly no way (definitely not public) to distinguish between them (and thus map them to their respective dtype objects).

I wrote #36 at least to raise a consistent error.

[honno]

I still don't think this is feasible/worth doing, and hopefully my custom error and more experience mitigates the problem you were having.