+1! Another question is what the default should be (technically Device("pony") is more strict), but probably better if we can keep the cpu default for backwards compatibility.

I think the CPU device should be the default. That way code that exists today should keep working and the only people who notice any changes are those who use the pony device.

This looks good so far. We need to make sure the semantics specified at https://data-apis.org/array-api/latest/design_topics/device_support.html#semantics are followed, namely, disallowing combining arrays from different devices, and making sure that if a function creates a new array based on an existing array that it uses the same device.

For tests, ideally this would be tested in array-api-tests, but right now device support is not tested at all there. If you just want to add some basic tests here for now, that is fien.

Finally, there is the devices inspection API. https://data-apis.org/array-api/latest/API_specification/generated/array_api.info.devices.html#array_api.info.devices We need to think about how that will work. One option would just be to create a small but fixed number of devices. Or we could add some flags to make it configurable https://data-apis.org/array-api-strict/api.html#array_api_strict.set_array_api_strict_flags

I've rebooted my work. The long pause is because I went on holiday :D

I think we have to limit ourselves to a fixed number of devices, otherwise we can't full fill the requirement that the info extension can provide a list of devices. So now you can use the CPU_DEVICE and the (creatively named) device1 and device2.

Slowly making progress towards the creation functions and "array combination" functions respecting the device

Do you use ruff or black or something like that for formatting?

It looks like it would be quite tricky to add device testing to array-api-tests. At least at my level of knowledge (unfamiliar with hypothesis and array-api-tests). It looks like you'd add a helper, maybe all_devices, similar to all_dtypes and then use it in the @given decorator. The tricky thing is that how to specify a device depends on the library, in a new version of the standard you could use the inspection API to get all devices. So yeah, for now I might add some basic testing here.

Do you use ruff or black or something like that for formatting?

There's no autoformatting on this repo.

It looks like it would be quite tricky to add device testing to array-api-tests. At least at my level of knowledge (unfamiliar with hypothesis and array-api-tests). It looks like you'd add a helper, maybe all_devices, similar to all_dtypes and then use it in the @given decorator. The tricky thing is that how to specify a device depends on the library, in a new version of the standard you could use the inspection API to get all devices. So yeah, for now I might add some basic testing here.

I think it would have to use the devices() function in the inspection API. That would mean that the tests would only work against the newest version of the standard and it would only work against the compat library, but I think that's fine. You'd also probably want to make it optional.

It's also possible to do some basic testing using the default device, like that x.device and device= are consistent.

The annoying thing for the test suite is making sure every function everywhere is passing device through properly so that everything gets created on the same device. It would also probably require some upstream fixes to the hypothesis array-api support.

I think what we need here are just some big parameterized tests combining basic example arrays with different devices across all the APIs. For instance, there's an existing test that checks type promotion and the "no mixing devices" test could look very similar to that.