Array.copy is not a no-op

Describe the issue:

The Array.copy docs say that .copy() is a no-op. However, if you actually do a copy a task is added to the graph and the .name of the original and new arrays are not equal.

https://docs.dask.org/en/stable/generated/dask.array.Array.copy.html

See the example below.

Minimal Complete Verifiable Example:

import dask.array as da
a = da.zeros(5)
b = a.copy()

Anything else we need to know?:

In the pyresample library we have custom objects that can contain dask arrays. In the __eq__ of these methods we do a shortcut to avoid having to compute a == b by doing a.name == b.name if the objects are dask arrays. In a lot of our use cases a and b are relatively large arrays that are loaded from files on disk.

This is coming up as a problem for me with xarray where after new behavior to their deep copy logic, dask arrays are now being copied. See https://github.com/pydata/xarray/issues/7111 and https://github.com/pydata/xarray/pull/7089.

Environment:

• Dask version: 2022.9.1
• Python version: 3.10
• Operating System: PopOS
• Install method (conda, pip, source): conda-forge

[ian-r-rose]

I think I agree with @djhoese that Array.copy should be a no-op. What would be the purpose of mapping copy across array blocks in the context of a Dask Array? (there may be some, but I can’t think of one). Morally speaking, Dask reserves the right to copy arrays, move memory around, and generally own the memory management of underlying blobs of data, and user copying of data seems counter to that.

I also don’t really like the difference in behavior for npartitions==1, which doesn’t seem very motivated. So I’d probably advocate for just removing that clause all-together. That seems like it would solve both @djhoese and @davidhassell’s issues (also, sorry for the slow response @davidhassell!).

I think that a more dask-y way to do something like an Array copy would be to use graph_manipulation.clone, which creates entirely new keys and forces them to be computed separately. But that’s a pretty advanced operation, and I don’t think 99% of user code will need it.

[davidhassell]

Thanks @djhoese and @ian-r-rose - looks good to me.