To me, adding enums as attributes of the `np.copy` function seems like a pretty good idea. This trick might resolve the only relatively important issue with Enums. Then, the benefits of Enum might outweigh the disadvantage of uncommon of usage of Enums in NumPy APIs. As an end user, I would like Enums rather than strings as the former would provide fixed number of choices (hence, easy debugging) as compared to the latter (in which case, infinite choices for passing strings and the code may work silently, imagine, passing, `if_neded` instead of `if_needed` and it working perfectly fine (silently). This thing has happened to me while using another library.
Any well-designed function accepting strings should do input validation though, to raise an error in case of mis-spelling.
I agree with this. Enums are nice _in theory_, but once you start using them you quickly figure out they're clunky, plus the all-caps looks bad (I'd consider ignoring that style recommendation). For API design they don't make all that much sense compared to "here's a list of strings we accept, and everything else raises an informative error". The only reasons I can think of to use them are:
1. Cases like never-copy, when there's a reason to have an object we can add a method too (`__bool__` here)
2. There's a long list of options and we want to give users a way to explore or iterate over those, so a public object is useful. so cases where we'd otherwise use a class (instance) instead of documenting the string options. I can't think of many examples like this, padding modes for `scipy.ndimage.convolve` is the only one that comes to mind.
In general I don't expect we'd need (m)any more. Hence I'd suggest adding a new namespace like `np.flags` is not a good idea. Right now all we need is a single object, if we end up going the enum route.
For this one, I'd say it kinda looks like we do need one, so then let's just add one and be done with it, rather than inventing odd patterns like tacking enum members onto an existing function.
Cheers,
Ralf