issues

In essence, I'm looking for the functionality of xarray.core.utils.maybe_wrap_array. I guess you are waiting for #964 to unify such functionality?

By changing a single np.asarray to np.asanyarray, it becomes possible to use ndarray subclasses within DataArray and Dataset. No guarantee is made at this point that their behaviour is retained under all circumstances, but for some use-cases it will work.

Particularly, this allows to store physical quantities represented using the Quantity subclass from the package python-quantities. In that sense, it is a partial fix for #525. Tests are included to highlight some of the things that do work, and some which don't. It does not work for coordinates when they are used as indexes, since pandas does not support ndarray subclasses. Most likely, it will also not work for any higher-level operation on the data such as those involving np.concatenate. Thus, any user of this feature should remain cautious. Nonetheless, for me, this change provides enough added value, such that I'd consider it worthwhile to keep, assuming it does not harm anywhere else. It does pass the tests on my machine (no dask though), let's see what travis says.

I expect that astropy's units would behave similarly, though since I never worked with them yet, I did not include any tests.

Consider this: import xarray as xr import numpy as np ds = xr.Dataset( data_vars=dict( v = ('y',np.r_[0:10]), ), coords=dict( y=xr.DataArray(np.r_[:10]/10,dims='x'), ), ) The dataset ds will end up having dimensions ('x', 'y') because of the coordinate y having dimensions ('x',). This seems to violate some of the internal assumptions (ds.indexes['y'].name turns out to be 'x'), consequently ds.sel(y=0) will throw an exception (ValueError: cannot use a dict-like object for selection on a dimension that does not have a MultiIndex).

I came across this situation when trying to generate a dataset with a coordinate that is a copy of another pre-existing coordinate, but under a different name. My expectation was that the coordinate would be renamed (doing so manually also doesn't work out of the box due to #1116). Of course that is not the only possible interpretation of the construct above, arguably it should raise an exception instead (which is what DataArray currently does in the corresponding case).

I did not follow the code deeply, but there clearly seems to be a huge overhead when indexing such arrays. In particular, in the following code ```python import xarray as xr import numpy as np

a = xr.DataArray([None for k in range(100)],dims='c') for k in range(a.c.size): a[k] = xr.DataArray(np.random.randn(1000,5),dims=['a','b'])

%prun a[0] ``` the indexing operation takes about 1 second on my machine, or 2 seconds when running under the profiler. The profiler output shows lots of functions with a recursive call count exceeding 100'000 (most likely iterating through each row of the contained sub-arrays). However, there is really no reason to iterate through the nested elements.

The documentation of DataArray.rename states that it renames the name of the DataArray and/or associated coordinates. However, if a name happens to be simultaneously the name of the array and of a coordinate, it only renames the array. This situation particularly arises when one tries to create a renamed coordinate to use on a different (new) array/dataset, as in that case the name of the only dimension of the coordinate array is the name of the array itself.