[Numpy-discussion] copy="never" discussion and no deprecation cycle?
sebastian at sipsolutions.net
Wed Jun 16 16:00:49 EDT 2021
(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
## 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
* 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
We discussed it briefly today in the triage call and we were leaning
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.
More information about the NumPy-Discussion