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.
W.r.t. NumPy's API: it could be okay to change the behavior of copy=False to make it more strict (no copies ever), because then at least errors will be raised and we can provide a message with instructions on how to fix it.
Resurfacing this discussion, since Sebastian asked me to comment.
After some reflection, I think my favorite solution now is True/False/None, including a deprecation cycle to migrate existing users of copy=False to use copy=None. This is the simplest adaptation of the existing argument, and in many cases where users are writing copy=False they may actually not be intending the current "maybe copy" behavior.
Strings would be appropriate if we were starting from scratch, but breaking backwards compatibility is very problematic.
I do like enums, but I recognize that they are not currently used in NumPy/SciPy, so they feel a little out of place, and expanding NumPy's namespace to add more enums also has a cost. I don't think the meme I linked to is entirely appropriate, because these aren't just three arbitrary modes -- two of the cases here really are "yes" or "no" copy, and the other is "maybe", which is a pretty common meaning for "None" as a default value (and users will rarely be writing copy=None themselves).