issue_comments

@NowanIlfideme h5py 3 changes with regard to strings is tracked also in #4570

This may be relevant here, maybe not, but it appears the HDF5 backend is also at odds with all the above serialization.

Our internal project's dependencies changed, and that moved the h5py version from 2.10 to 3.1; apparently there was a breaking change that meant unicode strings were either encoded or decoded as bytes. Thankfully we had a test for that, but figuring out what was wrong was difficult.

Essentially, netCDF4 files that were round-tripped to a BytesIO (via an HDF5 backend) had unicode strings converted to bytes. I'm not sure whether it was the encoding or decoding part, likely decoding, judging by the docs:

https://docs.h5py.org/en/stable/strings.html https://docs.h5py.org/en/stable/whatsnew/3.0.html#breaking-changes-deprecations

This might require even more special-casing to achieve consistent behavior for xarray users who don't really want to go into backend details (like me 😋).

Is it possible to preserve dtype when persisting xarray Datasets/DataArrays to disk?

Unfortunately, there is a frustrating disconnect between string data types in NumPy and netCDF.

This could be done in principle, but it would require adding our xarray specific convention on top of netCDF. I'm not sure this would be worth it -- we already end up converting np.unicode_ to object dtypes in many operations because we need a string dtype that can support missing values.

For reading data from disk, we use object dtype because we don't know the length of the longest string until we actually read the data, so this would be incompatible with lazy loading.

Currently, the dtype does not seem to roundtrip faithfully. When I write np.unicode_ / str to file, it gets transformed to object when I subsequently read it from disk. I am using xarray 0.10.8 with Python 3 on Windows.

This can be reproduced by inserting the following line in the script above (and adjusting the print statement accordingly)

python with xr.open_dataset(filename) as ds: read_dtype = ds['data'].dtype which gives:

Python version | NetCDF version | NumPy datatype | NetCDF datatype|Numpy datatype (read) -- | -- | -- | --|-- | Python 3 | NETCDF3 | np.string_ / bytes | NC_CHAR | \|S3 | | Python 3 | NETCDF4 | np.string_ / bytes | NC_CHAR | \|S3 | | Python 3 | NETCDF3 | np.unicode_ / str | NC_CHAR with UTF-8 encoding | object | | Python 3 | NETCDF4 | np.unicode_ / str | NC_STRING | object | | Python 3 | NETCDF3 | object bytes/bytes | NC_CHAR | \|S3 | | Python 3 | NETCDF4 | object bytes/bytes | NC_CHAR | \|S3 | | Python 3 | NETCDF3 | object unicode/str | NC_CHAR with UTF-8 encoding | object | | Python 3 | NETCDF4 | object unicode/str | NC_STRING | object |

Also object bytes/bytes seems not to roundtrip nicely as it seems to be converted to np.string_ / bytes.

Is it possible to preserve dtype when persisting xarray Datasets/DataArrays to disk?

Thanks a lot Stephan for writing that up!

The counter-argument is that it may not be worth changing this at this late point, given that we will be sunsetting Python 2 support by year's end.

This would be my personal opinion here. I you feel like this is something you'd like to provide before the last py2-compatible xarray comes out than I'm fine with it, but it shouldn't have top-priority...