@mathause Indeed, I am using engine="h5netcdf", invalid_netcdf=True.

I would also agree on the point that expanding the isinstance is not the best solution. Duck typing makes reliable instance checks quite painful.

I just came along this question as I tried something similar to @joshburkart. Using a string-enum instead, the code works in principle:

```python import enum

import numpy as np import pandas as pd import xarray as xr

class CoordId(str, enum.Enum): LAT = 'lat' LON = 'lon'

pd.DataFrame({CoordId.LAT: [1,2,3]}).to_csv()

Returns: ',CoordId.LAT\n0,1\n1,2\n2,3\n'

xr.DataArray( data=np.arange(3 * 2).reshape(3, 2), coords={CoordId.LAT: [1, 2, 3], CoordId.LON: [7, 8]}, dims=[CoordId.LAT, CoordId.LON], )

output

<xarray.DataArray (lat: 3, lon: 2)>

array([[0, 1],

[2, 3],

[4, 5]])

Coordinates:

* lat (CoordId.LAT) int64 1 2 3

* lon (CoordId.LON) int64 7 8

```

We however got somewhat ambivalent results, that the dimensions are still enum elements dims = (<CoordId.LAT: 'lat'>, <CoordId.LON: 'lon'>), but the coordinate names are the strings. After writing and reading the DataArray, everything is a plain string, we can still access the elements using the enum elements, as they are equal to the strings.

I agree, that the given example problem is related to a tolerance.

In principle, I see the problem in the current practice of just dropping data that doesn't align. If I perform an assignment =, I do not expect to lose any data.

Another example would be assigning:

python dataset['data2'] = xr.DataArray(np.random.random(50), dims=['x'], coords={'x': np.linspace(2, 12)})

This line of code would effectively do nothing, I generate data and upon assignment it is dropped.

But this might be a bit of a physiological question, what the governing design principle is. Personally I think, an assignment should only be possible if the assigned coordinates are a subset of the dataset's coordinates.

I am very sorry, I didn't realize that there had been a new release. Everything is fine after updating.

Sorry for the slow response, I have little time at the moment. The option invalid_netcdf=True is not yet in the latest release, is it? I get an TypeError. I would have to use a manually installed version of xarray to use it, right?

I agree that including it in NetCDF is the 'most sane' approach. I don't really know how much work it is, expanding the standard.

To be honest, I don't really care about NetCDF, for me xarray is just an incredible good way to make code more stable and readable (though it still has several usability issues). In my community everyone uses HDF5 anyway, so dropping compatibility is no big issue. I just want a way to persist data as it is and conveniently load it for plotting and post processing.

I would still encourage you to push saving of complex data. In most fields people use complex data and it is hard to convince them that they benefit from this great library, if saving simple data takes complicated keyword arguments and annoys you with warnings compared to a simple np.savez on regular ndarrays.

It might be interesting to see, if pythran is an alternative to Cython. It seems like it handles high level numpy quite well, and would retain the readability of Python. Of course, it has its own issues...

But it seems like other libraries like e.g. scikit-image made some good experience with it.

Sadly I can't be of much help, as I lack experience (and most importantly time).