ENH: unary functions overhaul; better input validation

[crusaderky]

xref #145

• Rewrite all unary functions with a generator
• Disallow numpy generics in binary functions, clip, and where
• Improve error message when the first argument of where is not an Array
• Test for device mismatches in the inputs of binary functions, clip, and where
• Test input-output device propagation in where

[crusaderky]

redundant with auto-applied fixture

[ev-br]

LGTM!

Let keep this PR open for a while though, in case somebody has opinions on generating unary functions from a decorator. I personally think this is a good change, but there were concerns in #100

[ev-br]

This and the following tests are great. I imaging we'll want to parrot them in array-api-tests at some point.

[crusaderky]

Note: this does not close #102 , as Python sneakily callls numpy.ndarray.__radd__. When array_api_strict.Array.__add__ fails. The opposite (LHS is numpy, RHS is array-api-strict) is also impossible to fix without disallowing __array__ and __buffer__.

[ev-br]

Note: this does not close #102 , as Python sneakily callls numpy.ndarray.radd. When array_api_strict.Array.add fails. The opposite (LHS is numpy, RHS is array-api-strict) is also impossible to fix without disallowing array and buffer.

Exactly.
I suggest we ignore this for the time being.

[crusaderky]

@ev-br good to merge now?

[lucascolley]

given the merge of gh-100, we may as well be consistent, so no worries from my side. Thanks both!

[lucascolley]

is the CI failure on main related to this PR? Or was that pre-existing?

[crusaderky]

is the CI failure on main related to this PR? Or was that pre-existing?

I'm on holiday and I can't bisect anything, but it looks to me like a scalar arg is being passed on 2023.12. If the issue is in array-api-strict or array-api-tests I can't debug from here, but I don't think it was caused by this PR.