@mattip I have some changes from something I was trying before that I think addresses #20326.

@asmeurer is this sufficient to bring np.unique(a, equal_nans=False) into compliance with the array API?

Bikeshedding on equal_nans, should it be maybe collapse_nans instead? They are not really "equal". What do others think?

Bikeshedding on equal_nans ...

This got a green light in the developer meeeting, so LGTM.

Actually, a little oops there. My/our argument was that we already have equal_nans, but that is not true. The parameter is called equal_nan on the other functions, so maybe that would be better?

The array API specifies that nans are not equal. See https://data-apis.org/array-api/latest/API_specification/generated/signatures.set_functions.unique_all.html#signatures.set_functions.unique_all for instance.

We would need to invert this flag in the array_api. The unique functions in the array API have new names so it wouldn't be backwards incompatible to change the default for them.

@asmeurer NumPy has chosen in np.unique to not follow the array API, rather to reduce all nans to a single value. This PR is to allow np.array_api.unique_all to use np.unique(..., equal_nan=False) under the hood. My question is if this PR is sufficient for the implementation of np.array_api.unique_all, which was the original request in #20326

Yes, I believe it should be. We just need to add equal_nans=False to the wrappers in the array API.