Skip to content

NEP 35: Finalize like= argument behaviour before 1.21 release #17075

Description

@seberg

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:

  1. (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())

  2. (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).

  3. Ensure that the name (currently like=) is thought out and has been discussed sufficiently.

  4. (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)

  5. (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):

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions