issue_comments

Is there any reason not to put the name of the type into attrs and just switch on that rather than the keys in data_vars?

Not really, I just thought the variables in the dataset were a way to uniquely identify its variant (i.e. do the validation of the dataset's structure). If you have different means to do so, of course you can use that instead.

Re TypedDict: the PEP introducing TypedDict especially mentions that it is only intended for Dict[str, Any] (so no subclasses of Dict for TypedDict). However, looking at the code of TypedDict, we should be able to do something similar for Dataset.

Edit: we'd still need to convince mypy that the custom TypedDict is a type...

so I'm curious if that has been discussed much

I don't think so? There were a few discussions about subclassing, but I couldn't find anything about static type analysis. It's definitely worth having this discussion, either here (repurposing this issue) or in a new issue.

you could emulate the availability of the accessors by checking your variables in the constructor of the accessor using ```python dataset_types = { frozenset("variable1", "variable2"): "type1", frozenset("variable2", "variable3"): "type2", frozenset("variable1", "variable3"): "type3", }

def _dataset_type(ds): data_vars = frozenset(ds.data_vars.keys()) return dataset_types[data_vars]

@xr.register_dataset_accessor("type1") class Type1Accessor: def init(self, ds): if _dataset_type(ds) != "type1": raise AttributeError("not a type1 dataset") self.dataset = ds though now that we have a "type" registry, we could also have one accessor, and pass a `kind` parameter to your `analyze` function:python def analyze(self, kind="auto"): analyzers = { "type1": _analyze_type1, "type2": _analyze_type2, }

if kind == "auto":
    kind = self.dataset_type
return analyzers.get(kind)(self.dataset)

```

If you just wanted to use static code analysis using e.g. mypy, consider using TypedDict. I don't know anything about mypy, though, so I wasn't able to get it to accept Dataset objects instead of dict. If someone actually gets this to work, we might be able to provide a xarray.typing module to allow something like (but depending on the amount of code needed, this could also fit in the Cookbook docs section): ```python from xarray.typing as DatasetType, Coordinate, ArrayType, Int64Type, FloatType

class Dataset1(DatasetType): longitude : Coordinate[ArrayType[Float64Type]] latitude : Coordinate[ArrayType[Float64Type]]

temperature : ArrayType[Float64Type]

def function(ds : Dataset1): # ... return ds ``` and have the type checker validate the structure of the dataset.

do you have any control on how the datasets are created? If so, you could provide a factory function (maybe pass in arrays via required kwargs?) that does the checks and describes the required dataset structure in its docstring.

If you have other questions about dtypes in xarray then please feel free to raise another issue about that.

Will do.

This probably won't happen in the near future, though, since the custom dtypes for numpy are still a work in progress (NEP-40, etc.)