issue_comments

Ah! Gotchya :)

A user might expect that they can write something like: python with nc.Dataset("tmp_example.nc") as ncfile: dstore = xr.backends.NetCDF4DataStore(ncfile) with xr.open_dataset(dstore) as data: ...

Currently this raises an error when the outer context manager exits.

So maybe this is a case for not closing files that were not opened by xarray.

@rsokl Yes, you're right for your issue. In my comment above I was referring to the case where the file was opened outside xarray.

Given that the user requested to close it, isn't it unambiguous that it should be closed?

Given the ambiguity, I think it would be reasonable to raise an error when trying to close a file not opened by xarray.

This would be a breaking change, so we if we change this we would need to start by issuing a warning.

It isn't obvious to me what the right behavior is here. I can see a case for either closing the file (the user did request it to be closed, after all) or leaving it open.

Sure, it's heavily depending on use case. But good to know what and where to look for in case anything unusual is going on.

Nevertheless it seems unusual, that opening a file outside xarray will be closed inside xarray. At least I would not expect it, to be closed.

It isn't obvious to me what the right behavior is here. I can see a case for either closing the file (the user did request it to be closed, after all) or leaving it open.

This doesn't work when it is opened via netCDF4 and NetCDF4DataStore.

python import netCDF4 as nc import xarray as xr ncfile = nc.Dataset("tmp_example.nc") dstore = xr.backends.NetCDF4DataStore(ncfile) data = xr.open_dataset(dstore) print(ncfile.isopen()) data.close() print(ncfile.isopen()) print(data.foo)

``` True False /home/miniconda/envs/xarray/lib/python3.8/site-packages/xarray/backends/netCDF4_.py in _getitem(self, key) 83 with self.datastore.lock: 84 original_array = self.get_array(needs_lock=False) ---> 85 array = getitem(original_array, key) 86 except IndexError: 87 # Catch IndexError in netCDF4 and return a more informative

netCDF4/_netCDF4.pyx in netCDF4._netCDF4.Variable.getitem()

netCDF4/_netCDF4.pyx in netCDF4._netCDF4.Variable.shape.get()

netCDF4/_netCDF4.pyx in netCDF4._netCDF4.Variable._getdims()

netCDF4/_netCDF4.pyx in netCDF4._netCDF4._ensure_nc_success()

RuntimeError: NetCDF: Not a valid ID ```

Also in @rsokl's case the data._file_obj is None after closing. First I thought that caching might be involved, but it doesn't seem the case.

Nevertheless it seems unusual, that opening a file outside xarray will be closed inside xarray. At least I would not expect it, to be closed. Should I open another issue for this, @shoyer?

Ah, gotchya. Yeah it was quite jarring to see that leaving the open_dataset context manager didn't produce any noticeable change in the data accessibility.

In my passing opinion, it seems like it would be best to protect people, especially those who don't understand what context managers do, from themselves and have a closed dataset raise upon being queried. This is how all "closed" objects behave in my experience.

I'll leave this issue open in case there is any useful discussion to host here. But feel free to close it if that is more appropriate.

Does querying a closed dataset automatically reopen it?

That's exactly right.

We could conceivably raise an error instead in these situations, since this is probably a case of user error.