issue_comments

Thanks, I missed that.

Is there a reason inheritance with a different init signature can't be allowed?

No strong reason -- we just didn't really consider (or test) inheritance in the current design. Certainly proposals (and PRs) for a subclassing API would be welcome.

At the very least, a big fat warning in the documentation would be helpful.

http://xarray.pydata.org/en/stable/internals.html#extending-xarray has some related guidance (I agree it could be louder)

This is a really painful bug since it leads to all sorts of obscure error messages. Is there a reason inheritance with a different __init__ signature can't be allowed? At the very least, a big fat warning in the documentation would be helpful.

That's the point of this issue, why. Read this comment of @shoyer.

@MaximilianR Okay, but this won't solve the current issue. If you override the init method when trying to subclass DataArray, subsequent accesses to some attributes (e.g. coords) will fail. No matter if you super up or not.

Why?

@MaximilianR Okay, but this won't solve the current issue. If you override the __init__ method when trying to subclass DataArray, subsequent accesses to some attributes (e.g. coords) will fail. No matter if you super up or not.

Also, even in OOP, I'm not sure every class needs to be designed to support inheritance. There are obvious applications where that is not practical.

Well, I think pure OOP should support class inheritance. In this case, you can subclass DataArray only if you do not customise the init method, which is not true inheritance ...

That's not the pythonic perspective (although I can see the attraction). The pythonic way is to override __init__ and super up

Well, I think pure OOP should support class inheritance. In this case, you can subclass DataArray only if you do not customise the __init__ method, which is not true inheritance ...

Yes, I have an alternative to suggest: initialise subclass instances in two steps, by creating a public method init(self, ...) or initialise(self, ...) to set custom attributes.

@mathieuS87 I'm not quite sure what you mean there. Do you have a suggested alternative?

@shoyer Then it is not OOP any more ...

Thanks @shoyer that works (:

@rafa-guedes the __init__ method needs to look like that of DataArray, e.g.,

class NewArray(xr.DataArray): def __init__(self, data, coords=None, dims=None, name=None, attrs=None, encoding=None, fastpath=False): # ...

or even simply:

class NewArray(xr.DataArray): def __init__(self, *args, **kwargs): # ...

Thanks @shoyer , what do you mean by preserve the signature of DataArray.__init__ please?

This was definitely caused by the refactor of DataArray internals in 0.7.0.

I don't think you were doing anything wrong, per se, it's just that the internal refactor changed what you can do with a subclasses in an unexpected way :(.

On the plus side, the new code should be better about preserving DataArray subclasses -- new DataArrays should be to the same type as parent objects. However, you will need to preserve the signature of DataArray.__init__, or replace the private _replace method on your subclass (I don't recommend this, because it's also definitely private API and not guaranteed to continue to work).