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

[Sebastian Berg]

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).

Strictly speaking, this is against the typical policy (one year of
warning/errors).  But nobody could think of a reasonable chance that
anyone actually uses it.  (For me just "policy" will be enough of an
argument to just take it slow.)

BUT: If nobody has *any* concerns at all, I think we may just end up
introducing the change right away.

The PR is: https://github.com/numpy/numpy/pull/19173


## The Feature

There is the idea to add `copy=never` (or similar).  This would modify
the existing `copy` argument to make it a 3-way decision:

* `copy=always` or `copy=True` to force a copy
* `copy=if_needed` or `copy=False` to prefer no-copy behavior
* `copy=never` to error when no-copy behavior is not possible
  (this ensures that a view is returned)

this would affect the functions:

* np.array(object, copy=...)
* arr.astype(new_dtype, copy=...)
* np.reshape(arr, new_shape, copy=...), and the method arr.reshape()
* np.meshgrid and possibly

Where `reshape` currently does not have the option and would benefit by
allowing for `arr.reshape(-1, copy=never)`, which would guarantee a
view.


## The Options

We have three options that are currently being discussed:

1. We introduce a new `np.CopyMode` or `np.<something>.Copy` Enum
   with values `np.CopyMode.NEVER`, `np.CopyMode.IF_NEEDED`, and
   `np.CopyMode.ALWAYS`

   * Plus: No compatibility concerns
   * Downside(?): This would be a first in NumPy, and is untypical
                  API due to that.

2. We introduce `copy="never"`, `copy="if_needed"` and `copy="always"`
   as strings (all other strings will be a `TypeError`):

   * Problem: `copy="never"` currently means `copy=True` (the opposite)
               Which means new code has to take care when it may run on
               older NumPy versions.  And in theory could make old code
               return the wrong thing.
   * Plus: Strings are the typical for options in NumPy currently.

3. Same as 2. But we take it very slow: Make strings an error right now
   and only introduce the new options after two releases as per typical
   deprecation policy.


## Discussion

We discussed it briefly today in the triage call and we were leaning
towards strings.  

I was honestly expecting to converge to option 3 to avoid compatibility
issues (mainly surprises with `copy="never"` on older versions).
But considering how weird it is to currently pass `copy="never"`, the
question was whether we should not change it with a release note.

The probability of someone currently passing exactly one of those three
(and no other) strings seems exceedingly small.

Personally, I don't have a much of an opinion.  But if *nobody* voices
any concern about just changing the meaning of the string inputs, I
think the current default may be to just do it.

Cheers,

Sebastian