On Thu, Jun 24, 2021, at 01:03, Ralf Gommers wrote:

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.

There are two arguments on the table that resonate with me:

1. Chuck argues that the current `copy=False` behavior (which, in fact, means copy-if-needed) is nonsensical and should be fixed.

2. Ralf argues that strings are ultimately the interface we'd like to see.

To achieve (1), we would need a deprecation cycle. During that deprecation cycle, we would need to provide a way to continue providing 'copy-if-needed' behavior. This can be achieved either with an enum or by accepting strings.

Stephan argues that accepting strings will be harmful to new code running on old versions of NumPy. I would still like to get a sense of how often this happens, or if that is a hit we are willing to take. If we decide that the concern is a significant one, then we would have to go the enum route, at least for a while. However, I see no compelling reason to have that enum live in the top-level namespace though: it is for relatively advanced use, and it will be temporary.

If we take the enum route, how do we get to (2)? We add a type check for a few releases and raise an error on string arguments (or, alternatively, handle 'always'/'never'/'if_needed' without advertising that functionality). Then, once we switch to string arguments, users will get an error (for old NumPy) or it will work as expected (for new NumPy).

I didn't think so originally, but I suppose we are in NEP territory now.

Stéfan