On 16/6/21 11:00 pm, Sebastian Berg wrote:
> Hi all,
> (sorry for the length, details/discussion below)
> On the triage call, there seemed a preference to just try to skip the
> deprecation and introduce `copy="never"`, `copy="if_needed"`, and
> `copy="always"` (i.e. string options for the `copy` keyword argument).
Why this may be controversial: today someone could be calling
|'||np.array(..., copy="never")', which would call| '|bool("never")',
which would evaluate to 1, and would end up| doing the exact opposite of
never. So their code is wrong, and they do not know it but are used to
the error. If we change this, it would silently fix their code to do
what they intended.
Is that a correct reading of the problem?
If so, I am in favor of the proposal to use string options in addition
to boolean options.
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.
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.
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.
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").
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.