Sorry for chiming in here. Using the example above, if we have the choice between: 1) sig.lowpass(0.2).multiply(3) 2) sig.accessorlib.lowpass(0.2).multiply(3) 3) sig.pipe(xdsp.lowpass, 0.2).pipe(np.multiply, 3) 4) sig(xdsp.lowpass, 0.2)(np.multiply, 3)

Of course, (1) is attractive because straight forward (as the dev of a small xarray accessor, I also forget very often that I have to add an attribute between the dataset and my function call). But (2) has the huge advantage that it clearly says where the code of the function is found, and where to ask questions when things do not work as expected.

(3) is OK for me since it is very explicit, but I find that (4) is quite ugly.

I think we probably need to agree to disagree here. I will update the docs in response to feedback (which is greatly appreciated!) and when I do so I will close out this issue.

Perhaps I will suggest DataArray.__call__ = DataArray.pipe (maybe that could be added in xarray ?

This seems too magical to me, but you are welcome to make another issue to see what others think. __call__ is not searchable in the way the .pipe is.

Python's introspection capabilities are powerful enough that users can find out such information.

I don't really agree here. Code is read in text form more often than it is interactively explored.

At Google, our Python style guide actually prohibits writing import like from xarray import Dataset. You have to write import xarray or import xarray as xr and always use the namespace.

And then there"s also the problem of accessors not being usable in functional programming paradigms.

xarray objects are already non-threadsafe, in the same way that the built-in list and dict are not threadsafe. I don't see how caching attributes changes this. You can choose whether or not to save state on the accessor (and of course, generally it would be better not to).

Finally, I'll note that we also have the .pipe method (e.g., array.pipe(square)), so if you just want functions that you can call with method chaining syntax, you don't even need to write an accessor at all.

You are certainly welcome to monkey patch -- that's the Python philosophy, after all -- but I'm not going to recommend it or make it easy. But I would even subclassing before considering monkey patching -- at least then your methods are contained to your own code, instead of contaminating a global namespace.

Is it because of namespace growth/conflicts? There are already many methods like diff, any which don't seem particularly more important than others. For instance, ndarray has no diff method yet you implement it.

Indeed. My thinking was the xarray.Dataset and xarray.DataArray are in the "xarray" namespace. We allow you to register an extension namespace, but want to keep it well contained and under one attribute, so it's clear(er) to users and developers what is going on, and where the code comes from.

A stricter approach would have been to put everything under an attribute just for extensions, e.g., Dataset.x.namespace instead of Dataset.namespace, but this gets even more cumbersome -- and also conflicts with variables named x!

Could you please give some clear arguments why you discourage the use of normal methods? The two arguments listed in the docs don't really make a compelling case against method monkey-patching, because 1. name clashes can be easily checked for either approach (in either case you just check the existence of a class attribute)

I'll add a note about the value of namespaces to the doc.

1. caching on the dataset sometimes makes no sense and just adds redundancy and complicates the design and registering of extra functionality

We could certainly turn this off (optionally) if there are cases where it does the wrong thing. Could you go into this in a little more detail, perhaps with a concrete example? My expectation was that this should have minimal design or performance downsides.

I don't see a conflict between encouraging accessors and making duplicate methods/functions. If you want duplicate method/functions, you can totally do that on an accessor class:

``` python import functools import xarray

@xarray.register_dataarray_accessor('custom') class CustomAccessor(object): def init(self, data_array): self._data_array = data_array

def patch_custom(func): @functools.wraps(func) def method(accessor, args, kwargs): return func(accessor._data_array, args, **kwargs) setattr(CustomAccessor, func.name, method) return func

@patch_custom def square(data_array): return data_array ** 2

xarray.DataArray([1, 2, 3], dims='x').custom.square()

<xarray.DataArray (x: 3)>

array([1, 4, 9])

Coordinates:

* x (x) int64 0 1 2

```

If you really desire, you can even make method-like accessors by adding a __call__ method, e.g.,

@xarray.register_dataarray_accessor('square') class Square(object): def __init__(self, data_array): self._data_array = data_array def __call__(self): return self._data_array ** 2

or even simpler

@xarray.register_dataarray_accessor('square') def square_accessor(data_array): def square(): return data_array ** 2 return square

I would definitely discourage writing too many of such methods, though.

Finally, it seems like the simplest solution to your concern about needing methods for Dataset.apply would be to register an accessor for Dataset as well, with register_dataset_accessor.