issue_comments

@gabicca given that we do say in our docs that we don't recommend subclassing xarray objects, I'm going to close this issue as a downstream "subclass at your own risk" problem. If you would like it to be easier to subclass, we would welcome your input here.

I'll leave that with you guys to decide. I've reported it, it's been looked at, and it has a record of it. So if the code is as you intended, I don't mind if the issue is closed.

Shall we close? It seems like the current code is what we want.

Because we want to get out the same type of Dataset (subclassed or not) as we input. That's what the T_Dataset type implies. And since we forced a Dataset at the end that wasn't the case.

In the example the naming and meaning of the arguments of the __init__ method are different from the Dataset base class.

Subclassing is often more reliable when it adheres to the Liskov Substitution Principle which states that objects of a superclass should be replaceable with objects of its subclasses and in other words: a subclass should only add functionality and not reduce it.

There are some other workarounds though:

If all you need is a convenient custom constructor then you could add a classmethod factory method to your subclass or even just use a plain function which returns a Dataset.

Another option is to convert your MyDataset instances to plain Dataset instances before passing them into xarray.concat, e.g. xarray.concat([ds.to_dataset() for ds in [ds1, ds2, ds3]], dim="coord1")

where your subclass may define as a convenience method:

def to_dataset(self): """Convert to plain Dataset.""" return xarray.Dataset(self, attrs=self.attrs)

Thank you for the answer. I'll look into implementing one of your suggestions (they're much better than what I had in mind).

I still don't understand the change that causes the error, though. If you want to instantiate a Dataset object, which you clearly do according to the args you pass in, why did that line have to be changed from explicitly calling Dataset? (By "you" I don't mean you personally, unless you actually made the change :) )

In the example the naming and meaning of the arguments of the __init__ method are different from the Dataset base class.

Subclassing is often more reliable when it adheres to the Liskov Substitution Principle which states that objects of a superclass should be replaceable with objects of its subclasses and in other words: a subclass should only add functionality and not reduce it.

There are some other workarounds though:

If all you need is a convenient custom constructor then you could add a classmethod factory method to your subclass or even just use a plain function which returns a Dataset.

Another option is to convert your MyDataset instances to plain Dataset instances before passing them into xarray.concat, e.g. xarray.concat([ds.to_dataset() for ds in [ds1, ds2, ds3]], dim="coord1")

where your subclass may define as a convenience method: ``` def to_dataset(self): """Convert to plain Dataset.""" return xarray.Dataset(self, attrs=self.attrs) ````