It looks like there are a number of places pandas uses arr.astype(..., copy=False) (although lots of other code does it too). Maybe running the pandas test suite against a numpy with this PR applied will be enough to discover whether that causes breakages?

You can use https://pandas-coverage-12d2130077bc.herokuapp.com to find which pandas tests hit a particular line of code in the pandas codebase.

It seems to me that there is a worm somewhere in all of this. What is astype() supposed to do? The documentation says that False allows a copy if needed. That is also true for the docs in the array-api.
But doesn't this change it so that False enforces something stricter at least sometimes?

So, is the meaning of copy=False just different for different functions? That solves a lot of problems, although it is also a bit confusing...

@seberg To sum up:
The new meanings for copy keyword for np.array, np.asarray and ndarray.astype are:

• True - make a copy
• None - make a copy if needed
• False - don't make a copy, or throw an exception that explains the new meaning of False and points to copy=None

For np.array the default stays as True, only np.array(..., copy=False) is impacted. For np.asarray the default changed to None (with the same meaning internally as False before) so if no copy keyword was provided then the behavior doesn't change (same for astype), and np.asarray(..., copy=False) is impacted.

(Also I reflected these changes in masked arrays and legacy matrices, let me know if I should revert any of public API changes)

I updated the whole codebase to adhere to these new meanings (if there are no caveats I can address it in downstream libraries).

What is astype() supposed to do?

Hmm I see that Array API defines np.astype with True/False only. There are a few options:

1. astype API definition should also include None for copy to be consistent with asarray/array, and we stay with the current PRs implementation.
2. astype keeps operating only with True/False as before, with False's original meaning (so astype's False -> asarray's None) (I think it's a bit confusing but also there are other functions with different copy meanings, like np.meshgrid)
   WDYT?

I am trying to avoid to think about it... I think it is strange to diverge the meaning, but breaking astype(copy=False) is a huge amount of churn that needs a bit clearer motivation.

Hi @seberg,

I updated the PR according to our discussion during the triage call and data-apis/array-api#721.

The new semantics None/True/False are now present only in np.array and np.asarray, and default values didn't change. np.astype and ndarray.astype copy behavior also stayed the same.

In the C-level code there is an updated definition of NPY_COPYMODE to adhere to the new semantics and a new NPY_ASTYPECOPYMODE enum for astype to keep the same behavior.

If it's Ok, I would update scipy and other libraries accordingly.

I do not see it as my decision to give the OK on changing how copy behaves in asarray, array, and friends. If there isn't a consensus, it should be in the NEP to propose to change it.

But, I do not like the change. The reason why I can live with the redefinition of copy=False in np.array(..., copy=False) is that it can be (and often is) spelled as np.asarray(...) (this is assuming downstream churn seems acceptable, I have no idea how bad it is). So, use asarray, not copy=None.
That is: copy=None is acceptable maybe, but partially because we at least normally do not use it explicitly (not sure about meshgrid, which defaults to copy=True).

In fact, we could just split out the array(..., copy=False) -> asarray refactor to make this PR smaller.

The interesting part is to try to pass it where we call array (probably only when copy is indicated).

In the triage meeting we decided to add the kwarg in a try, catch a kwarg error, and emit a deprecation error if the user's __array__ method does not allow the copy kwargs. We should make sure it is documented.

The interesting part is to try to pass it where we call __array__ (probably only when copy is indicated).

@seberg The only relevant place that I found where __array__ gets called was inside np.array implementation. I modified it in such a way that copy=... argument from np.array(...) is passed to __array__. If __array__ doesn't support it a warning is raised and it gets called again without copy.

Classes in tests/codebase that implement __array__ function now have dtype and copy arguments to adhere to the protocol - tomorrow I will update the documentation to cover this change.

Ok, I updated docs so that __array__ part mentions copy argument.

I am happy with the addition. Note that it will be quite noisy unless you do not pass copy=None and take it this very slow.

Code wise happy if you are. matching error exact is likely nice. Passing positionally for simplicity woukd be fine to me or using vectorcall would be best (much quicker probably and probably also simpler).

Merging this. Thanks @mtsokol! Also thanks for getting all the NEP 56 PRs across the line! 🎆 🥳

If you are reading this because this PR broke your nightly tests, take a look at the new docs, the NEP, and the scipy and scikit-learn PRs. If there is some sort of breakage in your code that is not straightforward to deal with in a backward compatible way, please open an issue.

Thanks for the hard work on this! Still a few things to iron out I think, xref gh-25916.