Before we release 1.20, we should finalize the behaviour. Or possibly hide/replace the API. Unless NEP 35 was officially accepted, there are still alternative suggestions such as np.get_array_module which may win the race.
There are also a few issues which require attention if we decide to keep the API largely untouched:
-
(This is currently NOT valid anymore, so it is the strict version) l = [1, 2]; np.asarray(l, like=l) is currently valid. However, modern API may want to only accept array-object as input and not objects such as lists/tuples, which the user should convert ahead of time. The above spelling could raise an error here, requiring the use of a different function (e.g. np.asduckarray()) to achieve the no-error version, which most existing API currently uses:
def strict_library(x):
x = np.asarray(x, like=x) # raise error if x is a list
def non_strict_library(x):
x = np.asduckarray(x)
the alternative might be to force the use of a different API:
def strict_library(x):
x = np.asarray(x, like=x, strict=True)
(Note that there might be a use for supporting an obj.__asduckarray__() method to mirror obj.__array__(), which would require np.asduckarray())
-
(This seems like an extension, since 1. is strict it is still possible) There may be a use for finding a common array-like for multiple input functions:
def function(arr1, arr2):
tmp = np.arange(1000, like=np.common_arraylike(arr1, arr2))
it was previously discussed that this could be achieved by making like work on tuples: np.arange(1000, like=(arr1, arr2).
-
Ensure that the name (currently like=) is thought out and has been discussed sufficiently.
-
(seberg) Are we sure that some of these function should never dispatch based on the existing (usually scalar) input? (I guess so, but I thought I saw np.linspace in there, which made me wonder, but I suppose its not there). In any case, we may want to review each function more individually. (Linspace is not include, so this seems fine)
-
(We currently dispatch aliases) Should we dispatch the aliases np.asarray(), etc. or rather only use the full np.array() call. The reason for inclusion is currently that CuPy would have issues with the last version, because it doesn't support the subok argument (there are no cupy subclasses):
Before we release 1.20, we should finalize the behaviour. Or possibly hide/replace the API. Unless NEP 35 was officially accepted, there are still alternative suggestions such as
np.get_array_modulewhich may win the race.There are also a few issues which require attention if we decide to keep the API largely untouched:
(This is currently NOT valid anymore, so it is the strict version)
l = [1, 2]; np.asarray(l, like=l)is currently valid. However, modern API may want to only accept array-object as input and not objects such as lists/tuples, which the user should convert ahead of time. The above spelling could raise an error here, requiring the use of a different function (e.g.np.asduckarray()) to achieve the no-error version, which most existing API currently uses:the alternative might be to force the use of a different API:
(Note that there might be a use for supporting an
obj.__asduckarray__()method to mirrorobj.__array__(), which would requirenp.asduckarray())(This seems like an extension, since 1. is strict it is still possible) There may be a use for finding a common array-like for multiple input functions:
it was previously discussed that this could be achieved by making like work on tuples:
np.arange(1000, like=(arr1, arr2).Ensure that the name (currently
like=) is thought out and has been discussed sufficiently.(seberg) Are we sure that some of these function should never dispatch based on the existing (usually scalar) input? (I guess so, but I thought I saw(Linspace is not include, so this seems fine)np.linspacein there, which made me wonder, but I suppose its not there). In any case, we may want to review each function more individually.(We currently dispatch aliases) Should we dispatch the aliases
np.asarray(), etc. or rather only use the fullnp.array()call. The reason for inclusion is currently that CuPy would have issues with the last version, because it doesn't support thesubokargument (there are no cupy subclasses):