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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
