On Mon, Jul 5, 2021 at 3:53 AM Stefan van der Walt <stef...@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.
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.
Cheers,
Ralf
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
