Repository navigation
RFC: add copy #495
Description
Some array libraries implement a .copy() method (like NumPy). While there are some indirect ways to get at this now (asarray, reshape, etc.), currently the API lacks a way to do this directly and without other potential side-effects. Should add a method (unlike a function) would ensure the new array has the original array's type simply. Curious if there is appetite for including this in the API.
Related is a question of what interplay there is with __copy__ and/or __deepcopy__ (if any).
Activity
rgommers commentedon Oct 12, 2022
Thanks @jakirkham. A couple of thoughts:
subok)copy(x)orx.copy()copy.copyandcopy.deepcopyI"d think (at least for NumPy)copyasmeurer commentedon Oct 12, 2022
Isn't this
asarray(x, copy=True)? Does that have side-effects?jakirkham commentedon Oct 20, 2022
To summarize the ask, library functions handling general arrays may want to copy as they want an array they can mutate safely without affecting user provided data.
We concluded that we want a function (not a method) and one needs to do a namespace lookup (
x.__array_namespace__) to figure it out (as the type is likely not known by the library).There is a separate question of what we call it. Either a new function (
copy,clone) or use an existing one (asarray(x, copy=True)). We would also want to spell out that some libraries (Dask, JAX, maybe others) may not actually copy the underlying data.__copy__and__deepcopy__are different enough (Dask would copy graphs, JAX something similar, etc.) that it is worth specifying this path may not copy the array data (if that is the user's concern) and that using the function above (name to be decided) would be preferred for data copying.asmeurer commentedon Oct 20, 2022
Right now
asarraysays thatcopy=TrueMUST copy the data, but maybe it should say it can not copy if it knows it solely owns the data and disallows mutation. Or can there be situations where a library thinks it solely owns the data but it doesn't actually, so it really has to do a real memory copy?rgommers commentedon Nov 4, 2022
@asmeurer good point. Maybe something like "must ensure that the returned array does not share data with another array, either by copying the data to a new memory location or in some other way (e.g., this property is guaranteed by design)".
[-]Adding `.copy()` method[/-][+]RFC: add `copy()`[/+][-]RFC: add `copy()`[/-][+]RFC: add `copy`[/+]lucascolley commentedon Dec 23, 2024
IMO this doesn't need to be added to the standard. In SciPy we use a private function called
xp_copya lot, which is just an alias forasarray(x, copy=True). If anyone would like that alias added to array-api-extra, feel free to open an issue.docs: clarify `copy` kwarg behavior in `asarray` for libraries disall…
kgryte commentedon Jan 23, 2025
I've opened #886 to hopefully satisfy concerns raised here and elsewhere: an array which can be mutated without affecting user data and allowing libraries such as JAX to avoid performing an explicit copy, which is unnecessary when provided a known array type.
kgryte commentedon Feb 26, 2025
Based on discussions during the 23 January 2025 workgroup meeting, consensus there was to update the page on copy-view mutability to include a section on the expected behavior of the
copykeyword argument. That has been done in #906.In that PR, it adds guidance requiring that, when
copy=True, unless an array library can guarantee that a returned array can be mutated without side effects, conforming array libraries should always perform a physical copy. This should address the desired behavior raised in this RFC.It was further recommended that
array-api-extrawould be a good place for a dedicatedcopyconvenience function which wrapsasarrayas described by @lucascolley above.docs: add design topic on `copy` keyword argument behavior