On Mon, Jul 5, 2021 at 3:53 AM Stefan van der Walt <stefanv@berkeley.edu> wrote:

On Sun, Jul 4, 2021, at 13:00, Ralf Gommers wrote:
I don't think so. We basically arrived at the solution, and there's a PR that is mostly done too. This really isn't that complicated that we should require a NEP.

Personally, I don't like np.CopyMode in the main namespace. If we can agree to stash it somewhere else, and tentatively aim to move to strings at point X in time for consistency with the rest of the API, I have no issue with going ahead.

I share your dislike, but I don't really see a better place where it doesn't make it even harder to spell, but I did just think of an alternative that may actually be quite reasonable: keep it private. The reason why Gagandeep started working on this is so we can have the never-copy behavior in the `numpy.array_api` namespace. For the `asarray` function there, the `copy` keyword is still boolean, with description:

Whether or not to make a copy of the input. If


                 
                  True

, always copies.


                 
                  False

, never copies for input which supports DLPack or the buffer protocol,

and raises


                 
                  ValueError

in case that would be necessary.


                 
                  None

, reuses existing memory buffer if possible, copies otherwise.

Default:


                 
                  None

In the end I think that's better than strings, and way better than enums - we just can't have that in the main namespace, because we can't change what `False` does.

Cheers,

Ralf