Reconsider copy parameter values for asarray function

[mtsokol]

Hi!

During yesterday's NumPy Triage Call we had a discussion about copy keyword for the asarray function, namely None/False/True choice for possible values.

The conclusion was that asarray(x, copy=None) doesn't convey the message of "make a copy only if needed", and could be replaced with something more expressive.

We came up with other possibilities, like string values:

• Always copy: asarray(x, copy="always")
• Copy if needed: asarray(x, copy="ifneeded")
• Never copy: asarray(x, copy="never")

My question is: Would it make sense to move from None/bool values for copy keyword to string values in the Array API?

Each library can then use and interpret None/bool as they wish, and only adhere to Array API with new string values that can be passed for library agnostic code.

[rgommers]

Thanks for the idea @mtsokol. My first thoughts:

• I believe we did consider this, and decided against it. I can't find the discussion anymore, IIRC the arguments given were related to static typing and validation of input strings.
• In case we don't reconsider the decision here, it still seems reasonable for NumPy to consider adding the string variant anyway if the NumPy team likes that - it's a compatible extension.
• Personally I'd say that the current description is sufficient, so the case for adding string variants doesn't seem too appealing. None is the default so typically isn't written in user code, and copy=True/False seems clear enough.

[kgryte]

I am in agreement with Ralf. I don't think it makes sense to add string variants, and I am not convinced that NumPy should do so either, as such an extension creates multiple ways to do the same thing and thus encourages portability concerns.

Additionally, we try to ensure kwargs are consistent across specification APIs. Another API having a copy kwarg is astype, which is also a boolean. So adding string variants for asarray may also mean similar considerations for other APIs, which I don't believe is desirable.

[rgommers]

Okay, let's close this for now then. The True/False/None should be clear enough. In case there's real-world experience that says otherwise in a while from now, we can revisit.

Thanks @mtsokol and @kgryte.