Here and below, why isdevice ahead oflike? Since one cannot use it for anything useful, my tendency would be to put it at the end.

Also, why not just set the default to"cpu"? That seems clearer. (Still fine to acceptNone).

Right now the function dispatch requireslike to be the last argument - here's a check that raisesRuntimeError if a function doesn't comply with it:

Can I keepdevice beforelike or should we update the__array_function__ protocol?

Also, why not just set the default to"cpu"? That seems clearer. (Still fine to acceptNone).

That's true that"cpu" is the only supported value, but I would prefer to stick to the Array API standard here. It defines the default value fordevice asNone:https://data-apis.org/array-api/latest/API_specification/generated/array_api.asarray.html

We're adding these keyword arguments for Array API compatibility only, so I would prefer to fully conform with it.

I don't think it matters from the Array API perspective, it doesn't make NumPy non-compliant, it just makes it explicit about what that default is.

But, I'll give a very slight vote to just keep itNone anyway. Just becuase I don't think the more explicitdevice="cpu" makes it clearer, since users should ignore it anyway (you only use it viaxp = arr.__array_namespace__() as an Array API user, never directly as a NumPy user).

The order doesn't matter much in principle, since it's keyword-only andlike is only for other non-numpy libraries as well. However, there's a bigger problem here:

>>>importnumpyasnp>>>importdask.arrayasda>>>d=da.ones((1,2))>>>np.asarray([1,2],device='cpu')array([1,2])>>>np.asarray([1,2],device='cpu',like=d)Traceback (mostrecentcalllast):CellIn[24],line1np.asarray([1,2],device='cpu',like=d)File~/code/tmp/dask/dask/array/core.py:1760in__array_function__returnda_func(*args,**kwargs)File~/code/tmp/dask/dask/array/core.py:4581inasarrayreturnfrom_array(a,getitem=getter_inline,**kwargs)TypeError:from_array()gotanunexpectedkeywordargument'device'

Thedevice keyword probably should not be added to the dispatchers for any of these creation functions. It looks like the__array_function__ protocol wasn't implemented in a forward-looking way - I haven't looked much deeper yet, but at first sight it may be the case that we can never add a new keyword to dispatched functions anymore.

In this case,device is here to support writing cross-library-compatible code via the array API standard. The dispatching protocols kinda were earlier attempts to do something similar. So probably they should not interact anyway?

Ah wait, it's maybe not that extreme -np.asarray([1, 2], like=d) still works, so new keywords are fine,as long as they are not used (then they don't get forwarded). Of course that's a bit funky, but there's no way to avoid it really.

>>>np.asarray([1,2],device='cpu')array([1,2])>>>np.asarray([1,2],like=d)dask.array<array,shape=(2,),dtype=int64,chunksize=(2,),chunktype=numpy.ndarray>>>>np.asarray([1,2],like=d,device='cpu')...TypeError:from_array()gotanunexpectedkeywordargument'device'

This would have been much more problematic if libraries like SciPy and scikit-learn supported non-numpy array inputs via__array_ufunc/function__. But since they squash such inputs anyway withnp.asarray, there shouldn't be too much of an issue in practice.

And it's fairly easy to add support for new keywords in Dask & co. They just need a new 2.0-compatible release that adds such support, and thendevice/like can be used together.

@rgommers - I've gotten quite used to updating astropy's__array_function__ wrappers to remain compatible with numpy functions -- and we've got tests to check that our signatures remain consistent. Of course it doesn't happen that often. So, I don't think that's a worry, and overall I'd tend to not special-case any arguments (i.e., pass it on if present).

On the order: iflike has to be last, then just keep it like that, sorry for not noticing myself.

Just to clarify: the check is only there to test habits, and probably mainly to make sure it is kwarg only.
It may have to be last in C (not sure), but it doesn't really matter anywhere here. But... it also doesn't matter a lot (especially since if someone cares, they can change it).

Thanks@mhvk, that is useful context. A test that flag mismatches sounds like a great idea. 🤞🏼 most implementers have that.