issue_comments

@kmuehlbauer you are right! I'm pretty sure the first time I tested it with just copy it didn't work. I just tried again and it works so I must have messed up somewhere.

I'll update my fork to just use dask_gufunc_kwargs.copy() in order to avoid adding another import statement.

@shoyer I hope it's much clear now, I tried to phrase what you suggested. @max-sixty That did the trick! Thank you both for your suggestions.

Any other feedback before we merge? (Errors are unrelated)

@max-sixty I think the typing errors are due to changing the Any to int and actually finding slice.

Thanks @max-sixty @shoyer !! I also agree with your suggestions and will be working on adding the default values during these days.

Is this being worked on?

If not, I can send a PR today since I have some code ready that might help add this functionality.

I think this could be achieved by checking len(dims) == len(shape) in the case where dims was explicitly provided, i.e., around this line:

Thanks for the suggestion. The raise now happens if len(dims) != len(shape) near the line you suggested.

Great, looking good @DangoMelon - I merged master to resolve a conflict - then we can get this in!

Thanks for the help! I'm glad to contribute to this project.

That's a good point. I think in this case, given that it's passed to an arg expected an array, we should raise on 0d.

I was expecting to rely on the current implementation of is_scalar to do the type checking since I'm moving _check_data_shape above as_compatible_data to do something like this

python if utils.is_scalar(data) and coords is not None:

Otherwise everything would be filter out since as_compatible_data returns a 0d given a scalar value. https://github.com/pydata/xarray/blob/8d46bf09f20e022baca98b4050584d93c0ea118b/xarray/core/variable.py#L195-L196

I can only imagine copying is_scalar but removing getattr(value, 'ndim', None) == 0 to filter out the 0d to only do the duplication on scalars.

Thanks for the feedback.

My inclination is to treat these like multi-dimensional arrays, in which case we should raise an error to avoid hiding errors.

I wasn't sure on how to treat 0-dimensional arrays and just assumed it to be the same as a scalar since this function considers them as so

https://github.com/pydata/xarray/blob/1ab7569561db50eaccbae977b0ef69993e0c0d0c/xarray/core/utils.py#L238-L248

Should I treat them like multi-dimensional arrays or leave the current behavior for consistency with the snippet above?

If the default value is NaN, we could reuse xarray's pre-existing sentinel value for NA:

Thanks for the advice, I'll be using this.

So far, this addition can do the following:

• Use a scalar value ```python

  xr.DataArray(5, coords=[('x', np.arange(3)), ('y', ['a', 'b'])])

<xarray.DataArray (x: 3, y: 2)> array([[5, 5], [5, 5], [5, 5]]) Coordinates: * x (x) int64 0 1 2 * y (y) <U1 'a' 'b' ```

• Use a scalar array ```python

  xr.DataArray(np.array(1.0), coords=[('x', np.arange(3)), ('y', ['a', 'b'])])

<xarray.DataArray (x: 3, y: 2)> array([[1., 1.], [1., 1.], [1., 1.]]) Coordinates: * x (x) int64 0 1 2 * y (y) <U1 'a' 'b' ```

• Match any number of dims ```python

  xr.DataArray(0, coords={'x': pd.date_range('20190101', '20190131'), 'y': ['north', 'south'], 'z': np.arange(4)}, dims=['w', 'x', 'y', 'p', 'z'])

<xarray.DataArray (w: 1, x: 31, y: 2, p: 1, z: 4)> array([[[[[0, ..., 0]],

     [[0, ..., 0]]],


    ...,


    [[[0, ..., 0]],

     [[0, ..., 0]]]]])

Coordinates: * x (x) datetime64[ns] 2019-01-01 2019-01-02 ... 2019-01-30 2019-01-31 * y (y) <U5 'north' 'south' * z (z) int64 0 1 2 3 Dimensions without coordinates: w, p ```

• Use None to get an empty array

```python

xr.DataArray(None, coords={'x': np.datetime64('2019-01-01'), 'y': np.arange(100), 'z': 'ST1', 'p': np.arange(10)}, dims=['y', 'p'])

<xarray.DataArray (y: 100, p: 10)> array([[ 4.047386e-320, 6.719293e-321, 0.000000e+000, ..., 6.935425e-310, 6.935319e-310, 0.000000e+000], [ 4.940656e-324, 6.935107e-310, 6.935432e-310, ..., 6.935432e-310, 1.086944e-322, 6.935430e-310], [ 6.935432e-310, 6.935319e-310, 2.758595e-313, ..., 6.935432e-310, 6.935432e-310, 6.935432e-310], ..., [ 6.781676e+194, 3.328071e-113, 9.124901e+192, ..., 2.195875e-157, -4.599251e-303, -2.217863e-250], [ 7.830998e+247, -8.407382e+089, 1.299071e+193, ..., 9.124901e+192, -4.661908e-303, 2.897933e+193], [ 1.144295e-309, 7.041423e+053, -8.538757e-210, ..., 1.473665e+256, -6.525461e-210, -1.665001e-075]]) Coordinates: x datetime64[ns] 2019-01-01 * y (y) int64 0 1 2 3 4 5 6 7 8 9 10 ... 90 91 92 93 94 95 96 97 98 99 z <U3 'ST1' * p (p) int64 0 1 2 3 4 5 6 7 8 9 ```

Any comment on what is missing or needs to be fixed is welcome.

Hi @max-sixty, I managed to fix it up a bit. It previously showed all the commits made by others collaborators since I forked the repo. I did a git rebase, solved all the merge conflicts and then force pushed it. It seems like some commits got duplicated though.

I am not sure what happened to the commit history. I might have messed up trying to update my local fork. Is there anything I can do to revert this?

Just realised most things broke with the change I made. I'll refactor it and try again.