Ok great thanks, solutions sound good

@lewisjarednz fyi

@shoyer can I bother you again now that CI is passing please?

The only other thing this needs is a test to check that the error is raised with the correct message (i.e. pytest.raises(TypeError, match="may fix this issue")

I believe that's covered by https://github.com/pydata/xarray/blob/ec2657bfc1a426aa3559243b02ecf48de6673506/xarray/tests/test_combine.py#L1109 (i.e. no change is needed to the existing code)

Alrighty updated, see what you think

We could try and tighten this up in a few ways (I'm not sure how much effort it is worth):

• only talk about cf_time if the error is in the time dimension (or if one of the types is cftime.datetime)
• only talk about cf_time if the function which tried to do the combining actually has this argument (e.g. combine_by_coords doesn't have use_cftime, only open_mfdataset does so the current implementation could be confusing), to do this I'd use a try except block further up the stack rather than altering the message in _ensure_same_types

Thoughts @mathause and @TomNicholas ?

Thanks @TomNicholas and @mathause. I've opened a new PR (#5776), turns out all the tests are well setup already, I just needed to be told where to look. Cheers!

use_cftime=True

I knew there must be a more elegant option, thanks!

@mathause what do you think?

Ignoring failing CI due to fsspec (see https://github.com/pydata/xarray/pull/5615#issuecomment-881679900)

xarray/tests/test_backends.py::test_open_fsspec appears to fail because of the release of ffspec 2021.7.0 so this PR will probably have to wait until a fix for that is added (presumably elsewhere to keep the changes clear).

Something like 59ed7d5? (Obviously missing proper tests but just to get a sense of whether the idea is plausible)

I tried pushing a fix. It's unclear to me whether the change should be in how the dtypes are inferred (given that the inference code seems to do what it is meant to...) or whether is_unicode_dtype simply needs to be updated to know about np.str_ (which is the fix I just tried).

What problem are you trying to solve here?

Somehow I ended up with np.str_ in a pandas dataframe (how is unclear to me but this seems to be a valid string type), which then exploded when I converted to xarray and attempted to save as netCDF. Minimal example below.

```python import numpy as np import pandas as pd

I don't know how the strings ended up being np.str_....

scenarios = [np.str_(v) for v in ["scenario_a", "scenario_b", "scenario_c"]] years = range(2015, 2100 + 1) tdf = pd.DataFrame( data=np.random.random((len(scenarios), len(years))), columns=years, index=scenarios, ) tdf.index.name = "scenario" tdf.columns.name = "year" tdf = tdf.stack() tdf.name = "tas"

txr = tdf.to_xarray()

raises error shown below

txr.to_netcdf("test.nc")

error

Traceback (most recent call last): File "scratch.py", line 20, in <module> txr.to_netcdf("test.nc") File ".../lib/python3.7/site-packages/xarray/core/dataarray.py", line 2741, in to_netcdf return dataset.to_netcdf(args, *kwargs) File ".../lib/python3.7/site-packages/xarray/core/dataset.py", line 1699, in to_netcdf invalid_netcdf=invalid_netcdf, File ".../lib/python3.7/site-packages/xarray/backends/api.py", line 1108, in to_netcdf dataset, store, writer, encoding=encoding, unlimited_dims=unlimited_dims File ".../lib/python3.7/site-packages/xarray/backends/api.py", line 1154, in dump_to_store store.store(variables, attrs, check_encoding, writer, unlimited_dims=unlimited_dims) File ".../lib/python3.7/site-packages/xarray/backends/common.py", line 256, in store variables, check_encoding_set, writer, unlimited_dims=unlimited_dims File ".../lib/python3.7/site-packages/xarray/backends/common.py", line 294, in set_variables name, v, check, unlimited_dims=unlimited_dims File ".../lib/python3.7/site-packages/xarray/backends/netCDF4_.py", line 464, in prepare_variable variable, self.format, raise_on_invalid_encoding=check_encoding File ".../lib/python3.7/site-packages/xarray/backends/netCDF4_.py", line 131, in get_datatype datatype = _nc4_dtype(var) File ".../lib/python3.7/site-packages/xarray/backends/netCDF4.py", line 154, in _nc4_dtype raise ValueError(f"unsupported dtype for netCDF4 variable: {var.dtype}") ValueError: unsupported dtype for netCDF4 variable: object ```

I agree, this should totally work. It's not obvious to me how to best fix it, though.

I assume it's not as trivial as just changing e.g. https://github.com/pydata/xarray/blob/f9a535c130615fe81379d785dffcc6c814fc1126/xarray/coding/strings.py#L32 to also know about np.str_?

@shoyer any further thoughts on this now that the scope is clearer?

So far I've just added a single test which fails. I don't think the test should fail although I'm not sure what the np.str_ type actually is so maybe this isn't a bug? Help/advice greatly appreciated.

If you can just add a what's new entry, I think this is ready to go!

Done, thanks!

Wicked thanks everyone!

I am not sure what is causing the CI failure, I don't think it's related to my changes