This change was prompted by the fact that getattr(data, 'values', data) affected any kind of data with a values attribute, which is not the desired behaviour for core.variable.as_compatible_data.

This also extends tests to assert that custom objects with such an attribute are not attempted to be converted.

I'm happy to write additional tests, if you could briefly sketch further requirements.

• [x] Implemented the changes
• [x] Closes #2097
• [x] Tests added
  • [ ] Sufficient?
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

This PR addresses #4014.

• [x] Closes #4014
• [x] Tests added or adjusted
• [x] Adjusted a test case where int64 coercion played a role
• [x] Explicit test for failing coercion (seems to be missing currently -- should this be added?)
• [x] Passes isort -rc . && black . && mypy . && flake8
• [x] Fully documented
• [x] Adjusted whats-new.rst for all changes ~~and api.rst for new API~~

xr.Dataset.to_netcdf does not seem to support writing data with unsigned integer dtypes, uint32, uint64 etc.. This seems to be the case for both scipy-based output formats, NETCDF3_CLASSIC and NETCDF3_64BIT.

It seems like dtype coercions for int64 and bool are done automatically for NetCDF3 in the xarray.netcdf3 module. Shouldn't data of signed dtypes then also be coerced, i.e. to their signed equivalent?

MCVE Code Sample

```python import numpy as np import xarray as xr

da = xr.DataArray(np.array([1,2,3], dtype='uint64'))

The following all fail:

da.to_netcdf("foo") # default format: scipy NETCDF3_CLASSIC da.to_netcdf("bar", format='NETCDF3_64BIT') da.astype('uint32').to_netcdf("baz") da.astype('uint16').to_netcdf("spam")

This works:

da.astype('int64').to_netcdf("working64") # is coerced da.astype('int32').to_netcdf("working32") # works natively ```

Importantly, this is with the netcdf4 python package not being installed, in which case that package would be used for writing rather than scipy's netcdf.

Expected Output

NetCDF3 file is written with an appropriately coerced data format, e.g. as done with int64.

Alternatively, writing data fails for all dtypes that would natively be unsupported, including int64 and bool.

Problem Description

Given that the infrastructure for coercion is already in place, it seems more consistent to me to apply coercion to all cases where it would lead to to_netcdf method calls succeeding rather than failing, not only to int64 and bool.

Ideally, coercion would happen towards another unsigned integer type. However, writing uint32 seems not to be possible, so it's not a 64bit/32bit issue. While the NetCDF Format Specification declares as only unsigned integer type NON_NEG, which I presume to be equivalent to uint32, writing unsigned integers seems not possible via scipy's NetCDF3 writer. Thus, the only viable coercion, as far as I see, would be to signed equivalents.

I see no new cast safety implications here, because the existing coerce_nc3_dtype function already checks if the original and cast arrays compare equivalently.

Versions