On Mon, Jul 5, 2021 at 3:53 AM Stefan van der Walt firstname.lastname@example.org 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. If False, never copies for input which supports DLPack or the buffer protocol, and raises ValueError in case that would be necessary. If 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.