Is your feature request related to a problem?

I frequently find myself wanting to annotate functions in terms of xarray objects that adhere to a particular schema. Given that a dataset's adherence to a schema is a matter of its structure/contents, it is unnatural to try to describe a schema as a subtype of xr.Dataset (or DataArray) (i.e. a type-checker ought not care that a dataset is an instance of a specific subclass of Dataset).

Describe the solution you'd like

Instead, it would be ideal to define a schema as a Protocol (structural subtype) of xr.Dataset. Unfortunately, one cannot subclass a normal class to create a protocol.

Thus, I am proposing that xarray provide Protocol-based descriptions of DataArray and Dataset so that users can describe schemas as structural subtypes of these classes. E.g.

```python from typing import Protocol

from xarray import DataArray from xarray.typing import DatasetProtocol

class ClimateData(DatasetProtocol, Protocol): lat: DataArray lon: DataArray temp: DataArray precip: DataArray

def process_climate_data(ds: ClimateData): ds.banana # type checker flags as unknown attribute ds.temp # type checker sees "DataArray" (as informed by ClimateData) ds.sel(lat=1.0) # type checker sees Dataset (as informed by DatasetProtocol) ```

The contents of DatasetProtocol would essentially look like a modified type stub for xarray.Dataset so the implementation details are relatively simple, I believe.

Describe alternatives you've considered

Creating a strict subtype of Dataset is not ideal for a few reasons:

1. Static type checkers would then expect to see that datasets must derive from that particular subclass, which is generally not the case.
2. The annotations / design of xarray.Dataset is too broad for describing a schema. E.g. the presence of __getattr__ prevents type checkers from flagging access to non-existent data variables and coordinates during static analysis. DatasetProtocol would need to be designed to be less permissive than this.

Additional context

Hopefully this could be leveraged by the likes of xarray-schema so that xarray schemas can be used to provide both runtime and static validation capabilities.

I'd love to get feedback on this, and would be happy to open a PR if xarray devs are willing to weigh in on the design of these protocols.

What happened?

The examples provided by this documentation reveal issues with the type-annotations for DataArray and Dataset. Running mypy and pyright on these basic use-cases, only slightly modified, produce type-checking errors.

What did you expect to happen?

The annotations for these classes should accommodate these common use-cases.

Minimal Complete Verifiable Example

```Python

run mypy or pyright on the following file to reproduce the errors

import numpy as np import xarray as xr import pandas as pd

data = np.random.rand(4, 3) locs = ["IA", "IL", "IN"] times = pd.date_range("2000-01-01", periods=4)

foo = xr.DataArray( data, coords=[times, locs], # error: List item 1 has incompatible type "List[str]"; expected "Tuple[Any, ...]" dims=["time", "space"], )

temp = 15 + 8 * np.random.randn(2, 2, 3) precip = 10 * np.random.rand(2, 2, 3) lon = [[-99.83, -99.32], [-99.79, -99.23]] lat = [[42.25, 42.21], [42.63, 42.59]]

A = { "temperature": (["x", "y", "time"], temp), "precipitation": (["x", "y", "time"], precip), }

C = { "lon": (["x", "y"], lon), "lat": (["x", "y"], lat), "time": pd.date_range("2014-09-06", periods=3), "reference_time": pd.Timestamp("2014-09-05"), }

ds = xr.Dataset( A, # error: Argument 1 to "Dataset" has incompatible type "Dict[str, Tuple[List[str], Any]]"; expected "Optional[Mapping[Hashable, Any]]" coords=C, # error: Argument "coords" to "Dataset" has incompatible type "Dict[str, Any]"; expected "Optional[Mapping[Hashable, Any]]" ) ```

MVCE confirmation

• [x] Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
• [x] Complete example — the example is self-contained, including all data and the text of any traceback.
• [x] Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
• [x] New issue — a search of GitHub Issues suggests this is not a duplicate.

Relevant log output

No response

Anything else we need to know?

Some of these errors are circumvented when one provides a literal inline, and thus exploit bidrectional inference, which may be why the current mypy tests ran in your CI miss these.

E.g.

```python from typing import Dict, Hashable, Any

def f(x: Dict[Hashable, Any]): ...

f({"hi": 1}) # this is ok -- uses bidirectional inference to see Dict[Hashable, Any]

x = {"hi": 1} f(x) # error: Dict[Hashable, Any] is invariant in Hashable, and is incompatible with str ```

This is a sticky situation as key is invariant even in Mapping: https://github.com/python/typing/issues/445. IMHO it would be great to tweak these annotations, e.g. Hashable -> Hashable | str | <other common coord types> to ensure that users don't face such false positives.

Environment

I don't understand why I am able to open and close a dataset, but then proceed to read data from said dataset.

I can open a 4 GB dataset and promptly close is, and then still access the data within, which appears to still be loading lazily. Does querying a closed dataset automatically reopen it?

MCVE Code Sample

```python import numpy as np import xarray as xr

ds = xr.Dataset({"foo": (("x",), np.random.rand(4,))}, coords={"x": [10, 20, 30, 40]}) ds.to_netcdf("tmp_example.nc") python

data = xr.open_dataset("tmp_example.nc") data.close() data.foo <xarray.DataArray 'foo' (x: 4)> array([0.894788, 0.017935, 0.696086, 0.827004]) Coordinates: * x (x) int64 10 20 30 40 ```

Expected Output

Because netCDF data sets are loaded lazily, I would imagine that, having not been touched when opened, that closing the data set would render it inaccessible

Versions