issue_comments

I have not used xarray recently, so I have no opinion there.

I don't know whether it's pandas or xarray's fault, but the behavior is definitely still present.

The bug is still valid.

Looks like the implicit nan-filling behavior is not present anymore, which likely killed the issue?

I don't know anything about the internals of xarray, and to be honest I rarely use it anymore. The issue remains valid (which is why I posted the reply above), but it's not going to be the end of the world if you close it as wontfix.

The issue is still relevant.

For the record, the repro code is now (e.g.) In [4]: from collections import * ...: import numpy as np ...: from xarray import * ...: ...: d1 = DataArray(np.empty((2, 2)), coords=OrderedDict([("foo", [0, 1]), ("bar", [0, 1])]), dims=["foo", "bar"]) ...: d2 = DataArray(np.empty((2, 2)), coords=OrderedDict([("bar", [0, 1]), ("foo", [0, 1])]), dims=["bar", "foo"]) ...: ...: ds = Dataset({"d1": d1, "d2": d2}) ...: ...: print(ds.d1) ...: print(ds.d2) <xarray.DataArray 'd1' (foo: 2, bar: 2)> array([[4.665651e-310, 0.000000e+000], [4.940656e-324, nan]]) Coordinates: * foo (foo) int64 0 1 * bar (bar) int64 0 1 <xarray.DataArray 'd2' (bar: 2, foo: 2)> array([[4.66565e-310, 0.00000e+000], [4.94066e-324, nan]]) Coordinates: * foo (foo) int64 0 1 * bar (bar) int64 0 1

Requesting a reopen: this issue is present again in 0.7.2.

Awesome, thanks. Any plans for a release soon? Feel free to close the issue.

Perhaps worth mentioning in the docs? The difference turned out to be a major bottleneck in my code.

In my case I could just switch to pandas, so I'll leave it as it is for now.

If you put arrays in a Dataset, you should not count on modifications to the arrays in the Dataset trickling back to the original arrays.

I think the most confusing part is that this the modifications will trickle down sometimes -- even though I'd prefer them to be always propagated, I would still mind much less if they were never propagated. At the end of the day it's not my call, feel free to close the issue if you want.

Sorry to raise the issue again but I just noticed that I had a couple of other places where I wrote quite naturally

d = DataArray(...) e = DataArray(...) ds = Dataset({"d": d, "e": e}) <work to initialize d and e>

which is equivalent to the form I was mentioning earlier (whether ds will actually get initialized properly depends on whether d and e have exactly matching coordinates).

To be honest I don't really understand what you mean by "Unfortunately, it's impossible to make such automatically aligned arrays views in general, because of numpy's memory model.": when the line ds = Dataset(...) gets executed, the ndarrays ds.d.values and ds.e.values either point to the old ndarrays d.values and e.values or to some newly created, coordinate-aligned ndarrays. If it is the latter, one can just modify d.values and e.values (as well as their coordinates systems) to point to the new ndarrays, right?

Thinking about it again, I think there could just be a mention in the docs that the pattern

foo = dataset[key] = DataArray(...)

should be avoided and written as

dataset[key] = DataArray(...) foo = dataset[key]

That should be good enough?

"If you use the DataArray constructor instead of inserting an item in a Dataset, the array values will always be a view." Can you explain what you mean here? I am using the DataArray constructor and then inserting the item in the Dataset.

I was more expecting that if the coordinates are not already aligned, then the DataArray gets modified to point to the "larger" array (though of course there may be issues with other variables pointing to the same array, etc.).

I like the pattern

some_explicit_dict_name[some_explicit_entry_name] = tmpvar = np.array(...) <... work work work on initializing tmpvar, expecting to initialize some_explicit_dict_name[some_explicit_entry_name]>

(because the explicit name is a bit too long to work with and I make it immediately clear what tmpvar is used for), but xray's behavior makes this work (on DataArrays) only sometimes, with no warning that this could fail to update the array I care about.

Not sure what the best approach is. Perhaps

tmpvar = dataset.new_dataarray(*args_and_**kwargs_to_DataArray.__init__)

which would make sure that no one else is pointing to the internal array at that point?

object arrays look fine to me, but I don't have a strong opinion either.