[Numpy-discussion] copy="never" discussion and no deprecation cycle?

[Stephan Hoyer]

On Thu, Jun 17, 2021 at 1:29 PM Matti Picus <matti.picus at gmail.com> wrote:

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210617/37ca14fd/attachment.html>