This would already be quite cool! But would the mechanism allow to pass arguments to the MyLibGis class at construction time? This might also be wordy, maybe something like ds = xray.DataArray(data, gis={'arg1':42})?

My suggested approach here would be to simply write functions instead, e.g.,

def make_gis_array(data, gis=None): data = xr.DataArray(data) data.attrs['gis'] = gis # or whatever

This is similar to how I would suggest inserting lazy variables, i.e., write your own functions using dask.array:

def add_lazy_vars(data): if 'P' in data and 'PB' in data: data['TP'] = data['P'].chunk() + data['PB'].chunk() return data

Back when I was doing spectroscopy in grad school, I wrote some routines to keep track of the units in Fourier transforms. I put this up on GitHub last year: https://github.com/shoyer/fourier-transform. I'm sure I'm not the only person to have written this code, but it still might be a useful point of departure.

As for xray, I agree that the full extent of what you're describing is probably out of scope for xarray itself. However, a basic labeled FFT does seem like it would be a useful addition to the core library.

Nevertheless, I am very interested in supporting external packages like this, either via subclassing or a similar mechanism.

One possibility would be a mechanism for registering "namespace" packages that define additional methods (as I have mentioned previously). You could write something like:

``` python

this code exists in your library "specarray"

class SpecArray(object): def init(self, xray_obj): self.obj = xray_obj

def fft(self):
    ...
    return freq, transformed_obj

xray.register_accessor('spec', SpecArray)

this is what user code looks like

import specarray import xray ds = xray.DataArray(...) ds.spec.fft() # calls the SpecArray.fft method ```

This might be easier than maintaining a full subclass, which tends to require a lot of work and presents backwards compatibility issues when we update internal methods.