issues

For a DataArray, when reusing a coordinate for multiple dimensions (is this expected usage?), it only shows once in the repr:

```python

x = xr.IndexVariable(data=range(5), dims='x') da = xr.DataArray(data=np.random.randn(5, 5), coords={'x': x}, dims=('x', 'x')) da <xarray.DataArray (x: 5)> array([[ 0.704139, 0.135638, -0.84717 , -0.580167, 0.95755 ], [ 0.966196, -0.126107, 0.547461, 1.075547, -0.477495], [-0.507956, -0.671571, 1.271085, 0.007741, -0.37878 ], [-0.969021, -0.440854, 0.062914, -0.3337 , -0.775898], [ 0.86893 , 0.227861, 1.831021, 0.702769, 0.868767]]) Coordinates: * x (x) int64 0 1 2 3 4 ```

I think it should be

python <xarray.DataArray (x: 5, x: 5)> array([[ ... ]]) Coordinates: * x (x) int64 0 1 2 3 4

Otherwise, everything appears to work exactly as I would expect.

This isn't an issue for Datasets:

```python

xr.Dataset({'da': da}) <xarray.Dataset> Dimensions: (x: 5) Coordinates: * x (x) int64 0 1 2 3 4 Data variables: da (x, x) float64 0.08976 0.1049 -1.291 -0.4605 -0.005165 -0.3259 ... ```

Thanks!

This adds support for object serialization using the netCDF4-python backend..

Minimum working (at least appears to..) example, no tests yet.

I added allow_object kwarg (rather than allow_pickle, no reason to firmly attach pickle to the api, could use something else for other backends).

This is now for:

• to_netcdf
• AbstractDataStore (a True value raises NotImplementedError for everything but NetCDF4DataStore)
• cf_encoder which when True alters its behaviour to allow dtype('O') through.

NetCDF4DataStore handles this independently from the cf_encoder/decoder. The dtype support made it hard to decouple, plus I think object serialization is a backend dependent issue.

There's a lot of potential for refactoring, just pushed this to get opinions about whether this was a reasonable approach - I'm relatively new to open source, so would appreciate any constructive feedback/criticisms!

• [ ] Closes #xxxx
• [ ] Tests added / passed
• [ ] Passes git diff upstream/master | flake8 --diff
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

^ these will come later!

At the moment, bool and dates aren't supported as attributes when serializing to netcdf4:

```python

da = xr.DataArray(range(5), attrs={'test': True}) da <xarray.DataArray (dim_0: 5)> array([0, 1, 2, 3, 4]) Dimensions without coordinates: dim_0 Attributes: test: True

da.to_netcdf('test_bool.nc') ... TypeError: illegal data type for attribute, must be one of dict_keys(['S1', 'i1', 'u1', 'i2', 'u2', 'i4', 'u4', 'i8', 'u8', 'f4', 'f8']), got b1

da = xr.DataArray(range(5), attrs={'test': pd.to_datetime('now')}) da <xarray.DataArray (dim_0: 5)> array([0, 1, 2, 3, 4]) Dimensions without coordinates: dim_0 Attributes: test: 2017-08-03 13:02:29

da.to_netcdf('test_dt.nc') ... TypeError: Invalid value for attr: 2017-08-03 13:02:29 must be a number string, ndarray or a list/tuple of numbers/strings for serialization to netCDF files ```

I assume bool attributes aren't supported by netcdf4-python and dates are difficult (could always just write these as a string), but this would be really nice to have if possible.

As an aside, using h5netcdf works for bools, but coerces them to int64.

I am looking to transition from pandas to xarray, and the only feature that I am really missing is the ability to seamlessly save arrays of python objects to hdf5 (or netCDF). This might be an issue for the backend netCDF4 libraries instead, but I thought I would post it here first to see what the opinions were about this functionality.

For context, Pandas allows this by using pytables' ObjectAtom to serialize the object using pickle, then saves as a variable length bytes data type. It is already possible to do this using netCDF4, by applying to each object in the array np.fromstring(pickle.dumps(obj), dtype=np.uint8), and saving these using a uint8 VLType. Then retrieving is simply pickle.reads(obj.tostring()) for each array.

I know pickle can be a security problem, it can cause an problem if you try to save a numerical array that accidently has dtype=object (pandas gives a warning), and that this is probably quite slow (I think pandas pickles a list containing all the objects for speed), but it would be incredibly convenient.

Just noticed this when reading through the code - VERY minor.

The Examples docstring for register_dataarray_accessor referred to register_dataset_accessor instead. Moved the example to register_dataset_accessor.

• [ ] Closes #xxxx
• [ ] Tests added / passed
• [ ] Passes git diff upstream/master | flake8 --diff
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

^ hopefully don't need to fill these in