Because we have lazy data reading functionality ```python import xarray as xr ds = xr.tutorial.open_dataset("air_temperature") var = ds.air.variable

print(type(var._data)) # memory cached array print(type(var._data.array.array)) # ah that's wrapping a lazy array, no data read in yet print(var._data.size) # can access size print(type(var._data.array.array)) # still a lazy array

.data forces a disk load

print(type(var.data)) # oops disk-load print(type(var._data)) # "still memory cached array" print(type(var._data.array.array)) # but that's wrapping numpy data in memory ```

<class 'xarray.core.indexing.MemoryCachedArray'> <class 'xarray.core.indexing.LazilyIndexedArray'> 3869000 <class 'xarray.core.indexing.LazilyIndexedArray'> <class 'numpy.ndarray'> <class 'xarray.core.indexing.MemoryCachedArray'> <class 'numpy.ndarray'>

This came up in the xarray office hours today, and I'm confused why this PR made any difference to the behavior at all? The .data property just points to ._data, so why would it matter which one we check?

Any chance of a release, this is quite breaking for large datasets that can only be out of memory.

👍🏾

Yes, without chunks of anything

Very smart test!

I'm not really opposed to this change, shape and dtype uses self._data aswell.

Without using chunks={} in open_dataset? I just find it a little odd that it's not a duck_array, what type is self._data?

This test just looked so similar to the tests in #6797. I think you can do a similar lazy test taking inspiration from: https://github.com/pydata/xarray/blob/ed60c6ccd3d6725cd91190b8796af4355f3085c2/xarray/tests/test_formatting.py#L715-L727

The data is loaded from an NetCDF store through open_dataset

No explicit test was added to ensure that the data wasn't loaded. I just experienced this bug enough (we would accidentally load 100GB files in our code base) that I knew exactly how to fix it.

If you want i can add a test to ensure that future optimizations to nbytes do not trigger a data load.

I was hoping the 1 line fix would be a shoe in.

Is that test targetting your issue with RAM crashing the laptop? Shouldn't there be some check if the values were loaded?

How did you import your data? self.data looks like this: https://github.com/pydata/xarray/blob/ed60c6ccd3d6725cd91190b8796af4355f3085c2/xarray/core/variable.py#L420-L435

I was expecting your data to be a duck_array?

It seems that checking hasattr on the _data variable achieves both purposes.

I think that at the very lease, the current implementation works as well as the old one for arrays that are defined by the sparse package.

Looking into the history a little more. I seem to be proposing to revert: https://github.com/pydata/xarray/commit/60f8c3d3488d377b0b21009422c6121e1c8f1f70

I think this is important since many users have arrays that are larger than memory. For me, I found this bug when trying to access the number of bytes in a 16GB dataset that I'm trying to load on my wimpy laptop. Not fun to start swapping. I feel like others might be hitting this too.

xref: https://github.com/pydata/xarray/pull/6797 https://github.com/pydata/xarray/issues/4842

I personally do not even think the hasattr is really that useful. You might as well use size and itemsize