2482 has now been merged which means that I can get the behaviour I want by using globally-permanent attrs to store arbitrary objects, and using accessors to attach methods to datasets.

I realised I'm massively overcomplicating this, I think all I need is the existing accessor functionality, and for attrs to always be preserved in order to get the behaviour I want. Therefore once #2482 is merged then I should be able to close this.

Sorry for the triple comment, but I could also do this:

If I do this: ```python @xr.register_dataset_accessor('bout') class BoutAccessor(object): def init(self, ds_object): self._data = ds_object

def set_options(self, options):
    self.options = options

@register_dataset_accessor('storm') class StormAccessor(BoutAccessor): def init(self, ds_object): super().init(ds_object)

def special_storm_plot()
    special_storm_plot(self._data, self.options)

``` then I can have BOUT-specific attributes and methods stored via the bout accessor, all of which are inherited by the more-specific storm accessor

```python ds = collect_data(path) options_obj = get_options(path)

ds.storm.set_options(options_obj) # access inherited methods from the bout accessor to store arbitrary extra data

ds.storm.special_storm_plot() # use data from the bout accessor when calling more-specific methods form the storm accessor

```

However then my attached objects don't survive the calling of xarray methods: python ds.storm.extra_info = 'options' new_ds = ds.isel(t=-1) print(new_ds.storm.extra_info) # AttributeError: 'StormAccessor' object has no attribute 'extra_info'

Or alternatively I suppose I could just store my options as an attribute on the accessor: ```python ds = collect_data(path) ds.bout.options = options_obj

Now I have an object which stores all the data I want

print(ds.bout.options) ```

That seems to be what I should have tried first.

In that case would it be possible to have multiple accessors, one for the core bout functionality and others for extensions for even-more-specific users? i.e an accessor for a code called Storm which is based on BOUT++: ```python print(ds) # xarray dataset

print(ds.bout.options) # BOUT-specific extra information

print(ds.storm.special_storm_plot()) # storm-user-group-specific method ``` Can an accessor inherit from another accessor class?

Accessors should only accept one argument, which is an xarray.Dataset.

Ah - I misunderstood how they work, if I do this:

```python @xr.register_dataset_accessor('bout') class BoutDataset(object): def init(self, ds_object): self.data = ds_object

def plot_tokamak():
    plot_in_bout_specific_way(self.data, self.extra_data)

then I can successfully use it like this:python ds = collect_data(path)

ds.bout.plot_tokamak() print(ds.bout.data) ``` Thanks!

What does your extra_data look like? Would it be possible to put it into xarray in the form of coordinates or attributes?

My extra_data is a nested-dictionary-like object containing everything in the simulation input file. This I can store in the attributes dictionary (that's what I'm doing at the moment), but I'm still interested in the problem of attaching arbitrary objects because because losing the attributes on operations is annoying and I envisage either myself or other users of the code wanting to store more complicated structures in the future. (For example an xgcm grid object)

Also the philosophy of the BOUT framework encourages each group of users to add their own functionality depending on what exactly they are solving. Some kind of base BoutDataset class which could then be further subclassed to add more specific functionality would fit best with this system. Would it be a terrible idea to subclass xr.Dataset into a BoutDataset, then decorate every inherited method by looping over them so that my extra attached objects are dealt with appropriately (maybe like this)? Would that not in theory give me the whole API of xarray while allowing me to attach arbitrary objects and methods to my class, and allowing further subclassing if desired?

(Sorry if this is too far off the topic of xarray, feel free to close it if you think this is not going to be relevant to any of the rest of the community.)

Your use of an xarray accessor class looks a little funny to me. Accessors should only accept one argument, which is an xarray.Dataset. If you want to make your own objects, that's fine, but I don't think there's any point in making them an accessor.

What does your extra_data look like? Would it be possible to put it into xarray in the form of coordinates or attributes? If so, that would probably be the preferred path.