<div dir="ltr"><div dir="ltr">On Thu, Jun 17, 2021 at 1:29 PM Matti Picus <<a href="mailto:matti.picus@gmail.com">matti.picus@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 16/6/21 11:00 pm, Sebastian Berg wrote:<br>
<br>
> Hi all,<br>
><br>
> (sorry for the length, details/discussion below)<br>
><br>
> On the triage call, there seemed a preference to just try to skip the<br>
> deprecation and introduce `copy="never"`, `copy="if_needed"`, and<br>
> `copy="always"` (i.e. string options for the `copy` keyword argument).<br>
><br>
<br>
Why this may be controversial: today someone could be calling <br>
|'||np.array(..., copy="never")', which would call| '|bool("never")', <br>
which would evaluate to 1, and would end up| doing the exact opposite of <br>
never. So their code is wrong, and they do not know it but are used to <br>
the error. If we change this, it would silently fix their code to do <br>
what they intended.<br>
<br>
<br>
Is that a correct reading of the problem?<br>
<br>
If so, I am in favor of the proposal to use string options in addition <br>
to boolean options.<br></blockquote><div><br></div><div>No, we aren't really concerned about users who write np.array(..., copy='never') today. This currently means np.array(..., copy=True), which is slightly unfortunate but not really a big deal.</div><div><br></div><div>The big concern is users who will write np.array(..., copy='never') in the future, when it becomes supported by NumPy, but their code gets run on an older version of NumPy, in which case it silently works in a different way.</div><div><br></div><div>This happens all the time. Even if we make copy='never' an error *today*, users will be encountering existing versions of NumPy for years into the future, so we won't be able to change the behavior of copy='never' for a very long time. Our deprecation policy says we would need to wait at least one year for this, but frankly I'm not sure that's enough for the possibility of silent bugs. 3-4 years might be more realistic.</div><div><br></div><div>Eric's concerns about existing uses of "if copy" inside NEP 18 overloads is another good point, though there may be relatively few users of this feature today given that np.array() is only recently overridable (via "like").</div><div><br></div><div>Overall, I think using an enum is the happiest situation. It's a slightly awkward API, to be sure, but not very awkward in the scheme of things, and it's better than needing to wait a long time for a final resolution. </div></div></div>