Closed mtsokol closed 5 months ago
Thanks for the idea @mtsokol. My first thoughts:
None
is the default so typically isn't written in user code, and copy=True/False
seems clear enough.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.
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.
Hi!
During yesterday's NumPy Triage Call we had a discussion about
copy
keyword for theasarray
function, namelyNone/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:
asarray(x, copy="always")
asarray(x, copy="ifneeded")
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.