# Extending xarray using accessors

Xarray is designed as a general purpose library and hence tries to avoid including overly domain specific functionality. But inevitably, the need for more domain specific logic arises.

## Composition over Inheritance

One potential solution to this problem is to subclass Dataset and/or DataArray to add domain specific functionality. However, inheritance is not very robust. It’s easy to inadvertently use internal APIs when subclassing, which means that your code may break when xarray upgrades. Furthermore, many builtin methods will only return native xarray objects.

The standard advice is to use composition over inheritance, but reimplementing an API as large as xarray’s on your own objects can be an onerous task, even if most methods are only forwarding to xarray implementations. (For an example of a project which took this approach of subclassing see UXarray).

If you simply want the ability to call a function with the syntax of a method call, then the builtin `pipe()` method (copied from pandas) may suffice.

## Writing Custom Accessors

To resolve this issue for more complex cases, xarray has the `register_dataset_accessor()`, `register_dataarray_accessor()` and `register_datatree_accessor()` decorators for adding custom “accessors” on xarray objects, thereby “extending” the functionality of your xarray object.

Here’s how you might use these decorators to write a custom “geo” accessor implementing a geography specific extension to xarray:

    import xarray as xr

    @xr.register_dataset_accessor("geo")
    class GeoAccessor:
        def __init__(self, xarray_obj):
            self._obj = xarray_obj
            self._center = None

        @property
        def center(self):
            """Return the geographic center point of this dataset."""
            if self._center is None:
                # we can use a cache on our accessor objects, because accessors
                # themselves are cached on instances that access them.
                lon = self._obj.latitude
                lat = self._obj.longitude
                self._center = (float(lon.mean()), float(lat.mean()))
            return self._center

        def plot(self):
            """Plot data on a map."""
            return "plotting!"

In general, the only restriction on the accessor class is that the `__init__` method must have a single parameter: the `Dataset` or `DataArray` object it is supposed to work on.

This achieves the same result as if the `Dataset` class had a cached property defined that returns an instance of your class:

    class Dataset:
        ...

        @property
        def geo(self):
            return GeoAccessor(self)

However, using the register accessor decorators is preferable to simply adding your own ad-hoc property (i.e., `Dataset.geo = property(...)`), for several reasons:

1. It ensures that the name of your property does not accidentally conflict with any other attributes or methods (including other accessors).

2. Instances of accessor object will be cached on the xarray object that creates them. This means you can save state on them (e.g., to cache computed properties).

3. Using an accessor provides an implicit namespace for your custom functionality that clearly identifies it as separate from built-in xarray methods.

Note

Accessors are created once per DataArray and Dataset instance. New instances, like those created from arithmetic operations or when accessing a DataArray from a Dataset (ex. `ds[var_name]`), will have new accessors created.

Back in an interactive IPython session, we can use these properties:

    In [1]: ds = xr.Dataset({"longitude": np.linspace(0, 10), "latitude": np.linspace(0, 20)})

    In [2]: ds.geo.center
    ---------------------------------------------------------------------------
    AttributeError                            Traceback (most recent call last)
    Cell In[2], line 1
    ----> 1 ds.geo.center

    File /build/python-xarray-69jxB9/python-xarray-2025.01.2/xarray/core/common.py:305, in AttrAccessMixin.__getattr__(self, name)
        303         with suppress(KeyError):
        304             return source[name]
    --> 305 raise AttributeError(
        306     f"{type(self).__name__!r} object has no attribute {name!r}"
        307 )

    AttributeError: 'Dataset' object has no attribute 'geo'

    In [3]: ds.geo.plot()
    ---------------------------------------------------------------------------
    AttributeError                            Traceback (most recent call last)
    Cell In[3], line 1
    ----> 1 ds.geo.plot()

    File /build/python-xarray-69jxB9/python-xarray-2025.01.2/xarray/core/common.py:305, in AttrAccessMixin.__getattr__(self, name)
        303         with suppress(KeyError):
        304             return source[name]
    --> 305 raise AttributeError(
        306     f"{type(self).__name__!r} object has no attribute {name!r}"
        307 )

    AttributeError: 'Dataset' object has no attribute 'geo'

The intent here is that libraries that extend xarray could add such an accessor to implement subclass specific functionality rather than using actual subclasses or patching in a large number of domain specific methods. For further reading on ways to write new accessors and the philosophy behind the approach, see https://github.com/pydata/xarray/issues/1080.

To help users keep things straight, please let us know if you plan to write a new accessor for an open source library. Existing open source accessors and the libraries that implement them are available in the list on the Xarray related projects page.

To make documenting accessors with `sphinx` and `sphinx.ext.autosummary` easier, you can use sphinx-autosummary-accessors.