issues

What happened?

I'm using xarray.where to mask data: xr.where(ds == ds.attrs["_FillValue"], nan, ds). This loses the attributes on ds even if I pass keep_attrs=True.

What did you expect to happen?

I expect that if I use keep_attrs=True, either via xr.set_options or directly passed to xr.where, that attributes on the dataset are retained.

Minimal Complete Verifiable Example

Python import xarray as xr a = xr.DataArray([0], attrs={"a": "b"}) with xr.set_options(keep_attrs=True): a2 = xr.where(a==0, 0, a, keep_attrs=True) print(a2.attrs)

MVCE confirmation

• [X] Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
• [X] Complete example — the example is self-contained, including all data and the text of any traceback.
• [X] Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
• [X] New issue — a search of GitHub Issues suggests this is not a duplicate.

Relevant log output

Python {}

Anything else we need to know?

I can make a workaround by turning the logic around, such as xr.where(a!=0, a, 0), which does retain attributes.

The workaround works in this case, but a!=0 is not always the same as a==0, so it would be preferable if the attributes were retained either way.

Environment

(I am almost sure this already exists as an issue, but I can't find the original)

What happened:

When assigning nan to a integer-dtype array, the nan gets incorrectly inverted to int.

What you expected to happen:

I expect to get a ValueError, like I get for pure numpy arrays.

Minimal Complete Verifiable Example:

python import xarray import numpy da = xarray.DataArray(numpy.array([0,1], dtype="u8")) da[0] = numpy.nan print(da)

Gives:

<xarray.DataArray (dim_0: 2)> array([9223372036854775808, 1], dtype=uint64) Dimensions without coordinates: dim_0

Anything else we need to know?:

In numpy the equivalent code raises ValueError

This is related but different from #2945. In #2945, xarray behaves the same as numpy. In #4612, xarray behaves differently from numpy.

Environment:

```python import numpy import xarray

da = xarray.DataArray(numpy.arange(103).reshape(10, 3), dims=("x", "y"), coords={"foo": (("x", "y"), numpy.arange(310).reshape(10,3))})

print(da.shape == da["foo"].shape)

da2 = numpy.insert(da, 3, 0, axis=0)

print(da2.shape == da2["foo"].shape) ```

Problem description

Running the code snippet gives

True False

and does not raise any exception. In the resulting da2, the shape for da2 and da2['foo'] are different: we have changed the size of da2 without changing the size of its corresponding foo coordinate. This happens silently, no exception is thrown. Inevitably, this is likely to result in problems at a later stage.

Expected Output

I would expect to get an exception, telling me that the insertion has failed because there are coordinates associated with the axis along which we are inserting values. It would be nice to have an xarray.insert that can handle this, for example, by forcing us to provide corresponding insertion values for the coordinates.

Output of xr.show_versions()

Currently, ds['a'] = ((), ma.masked) where ds is an xarray.Dataset gives ValueError: Could not convert tuple of form (dims, data[, attrs, encoding]): ((), masked) to Variable., whereas ds['a'] = (), ma.MaskedArray(0.0, True) works (it sets the indicated value to NaN). Should assigning ma.masked be equivalent to assigning ma.MaskedArray(0.0, True), or are there good reasons for the difference in behaviour?

In pandas commit https://github.com/pandas-dev/pandas/commit/793020293ee1e5fa023f45c12943a4ac51cc23d isna and notna were added as aliases for isnull and notnull. Those need to be added to PANDAS_UNARY_FUNCTIONS for xarray datasets notnull to work. Closes #1663.

• [ ] Closes #1663

Note: I'm not sure how to test for this, as I think existing tests should be already failing due to this. In fact, when I run nosetests on my system I get 123 skips, 29 errors and 2 failures, none of which are related to my addition, so there must be something wrong on my system.

I did not try the flake8 test and I think new documentation is exaggerated in this case.

Bugfix: error message for KeyError has spurious %r, into which the dimension name is apparently intended to be substituted, but wasn't. Substitute the dimension name so that the error message is more informative.

Fix small mistake in documentation. It said NaN is not a valid dtype for integer dtypes, this surely should be NaN is not a valid value for integer dtypes.