Thanks. Noting that chunks and name are both optional arguments would be welcome. Do you want to do that it this pull request?

I just pushed another commit, it turns out the name argument wasn't supported by the the *like functions, the reason being that these are explicitly defined here:

The wrapped forms of *like are not public, as far as I can tell:

grep -Hrn "from .wrap"
core.py:4627:    from .wrap import empty
creation.py:25:from .wrap import empty, ones, zeros, full
rechunk.py:24:from .wrap import empty
reductions.py:20:from .wrap import zeros, ones
routines.py:20:from .wrap import ones
__init__.py:220:    from .wrap import ones, zeros, empty, full

They are used internally:

grep -Hrn "wrap\."
array/core.py:3490:            return wrap.empty_like(meta, shape=shape, chunks=shape, dtype=meta.dtype)
array/core.py:4277:            return wrap.empty_like(meta, shape=shape, chunks=shape, dtype=meta.dtype)
array/overlap.py:354:        c = wrap.full_like(
array/overlap.py:509:                empty = wrap.empty_like(

But appear to take a meta numpy array as their first argument.

Additionally, the *like functions in creation all follow this pattern:

    a = asarray(a, name=False)
    return ones(
        a.shape,
        dtype=(dtype or a.dtype),
        chunks=(chunks if chunks is not None else a.chunks),
   )

It seems straightforward to include the a = asarray(a, name=False) line in the wrapping functions.

Currently, the *like functions in creation also do not support the memory order keyword, while the non-like functions do:

In [8]: a = da.empty((10, 10), order="F")

In [9]: a.compute().flags
Out[9]:
  C_CONTIGUOUS : False
  F_CONTIGUOUS : True
  OWNDATA : True
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False

So I'm a little confused:

• Maybe rename the wrap.*like functions that are only used internally? (e.g. like_meta?)
• Generate public *like functions in wrap, and remove the repetition in creation? Due to *args, **args they would also support all numpy keywords like order, although not "K" and "A" options if a is a dask.array? https://docs.scipy.org/doc/numpy/reference/generated/numpy.full_like.html
• Alternatively, just make everything explicit in creation for all the wrapped functions, copy and edit the numpy docstrings. Taking the argument check of full into accoumt, 5/8 wrapped functions already have explicit definitions (full, full_like, zeros_like, ones_like, empty_like).
• Adding order would be a breaking change for *like functions, as I think you'd want the numpy argument first, dask argument (name, chunks) last.

I think we'd be OK with adding an order argument to the public da.*_like methods.

It seems straightforward to include the a = asarray(a, name=False) line in the wrapping functions.

That's probably fine, assuming the tests pass.

I'm less sure about your other suggestions / questions. There's a bit of repetition but it seems to be working ok.

Yeah, you're right. The latest commits are just the minimal changes necessary, as well as some minor polishes.

@Huite is this good to go? Maybe with just one more look over from @TomAugspurger?

Lets merge this, and I'll cleanup whatever else in #6276. Easier for me to fix merge conflicts than ask others to.