It looks like there are a number of places pandas usesarr.astype(..., copy=False) (althoughlots 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 usehttps://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 isastype() supposed to do? The documentation says thatFalse allows a copy if needed. That is also true for the docs in the array-api.
But doesn't this change it so thatFalse enforces something stricter at least sometimes?

So, is the meaning ofcopy=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 forcopy keyword fornp.array,np.asarray andndarray.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 tocopy=None

Fornp.array the default stays asTrue, onlynp.array(..., copy=False) is impacted. Fornp.asarray the default changed toNone (with the same meaning internally asFalse before) so if nocopy keyword was provided then the behavior doesn't change (same forastype), andnp.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 isastype() supposed to do?

Hmm I see that Array API definesnp.astype withTrue/False only. There are a few options:

1. astype API definition should also includeNone forcopy to be consistent withasarray/array, and we stay with the current PRs implementation.
2. astype keeps operating only withTrue/False as before, withFalse's original meaning (soastype's False ->asarray's None) (I think it's a bit confusing but also there are other functions with differentcopy meanings, likenp.meshgrid)
   WDYT?

I am trying to avoid to think about it... I think it is strange to diverge the meaning, but breakingastype(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 anddata-apis/array-api#721.

The new semanticsNone/True/False are now present only innp.array andnp.asarray, and default values didn't change.np.astype andndarray.astypecopy behavior also stayed the same.

In the C-level code there is an updated definition ofNPY_COPYMODE to adhere to the new semantics and a newNPY_ASTYPECOPYMODE enum forastype to keep the same behavior.

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

I donot see it as my decision to give the OK on changing how copy behaves inasarray,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 ofcopy=False innp.array(..., copy=False) is that it can be (and often is) spelled asnp.asarray(...) (this is assuming downstream churn seems acceptable, I have no idea how bad it is). So, useasarray, notcopy=None.
That is:copy=None is acceptable maybe, but partially because we at least normally do not use it explicitly (not sure aboutmeshgrid, which defaults tocopy=True).

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

The interesting part is to try to pass it where we callarray (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 thecopy 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 insidenp.array implementation. I modified it in such a way thatcopy=... argument fromnp.array(...) is passed to__array__. If__array__ doesn't support it a warning is raised and it gets called again withoutcopy.

Classes in tests/codebase that implement__array__ function now havedtype andcopy arguments to adhere to the protocol - tomorrow I will update the documentation to cover this change.

Ok, I updated docs so that__array__ part mentionscopy 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, xrefgh-25916.