`at.set` methods raise "assignment destination is read-only" with `array_api_strict` arrays

[mdhaber]

at.set rnethods return modified copies of read-only NumPy arrays, but they raise for read-only array_api_strict arrays.

import array_api_extra as xpx
import array_api_strict as xp
# import numpy as xp  # NumPy works

x = xp.zeros(())
x = xp.broadcast_to(x, (2,))
x = xpx.at(x)[0].set(1)
# ValueError: assignment destination is read-only

While we're at it, what do you think about making ... a default value for the second argument/index of at?

[lucascolley]

cc @crusaderky

[crusaderky]

Works as intended. array-api-strict is designed to be a generic and opaque Array API compliant backend, that offers strictly what the Array API requires and nothing more. Any special-case code path for it would defeat its purpose.

All special-case code paths in array-api-extra, implemented for backends other than array-api-strict, are hacks around issues either in the Array API itself or in its implementation by the backends.

The specific failure you report highlights that there is no way in the Array API to mark an array as read-only (data-apis/array-api#845).

[mdhaber]

Ok. The thought was that array API extra is supposed to provide extra functionality on top of the standard.

Is "as well as read-only arrays from libraries not explicitly covered by array-api-compat, are not supported by update methods." intended to hint at this gotcha?

Why go through the trouble to avoid this with NumPy, then? Usability is limited by the most restrictive backend.

[crusaderky]

Ok. The thought was that array API extra is supposed to provide extra functionality on top of the standard.

Yes, and that's why it supports special code paths for a bunch of backends.
array-api-strict is specifically design to model all backends not explicitly accounted for, so it should not have any special code paths.

Is "as well as read-only arrays from libraries not explicitly covered by array-api-compat, are not supported by update methods." intended to hint at this gotcha?

Yes. For example it won't work if you wrap a JAX array with marray, because it won't benefit from all the JAX-specific code paths.
I'm very open to the idea of adding marray as an explicit special case to array-api-compat and array-api-extra; it just requires legwork as well as and buy-in from maintainers that it is worth the extra complexity.

Why go through the trouble to avoid this with NumPy, then? Usability is limited by the most restrictive backend.

scipy is full of examples where a function won't work on one or two backends for whatever reasons.