html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/1288#issuecomment-283158736,https://api.github.com/repos/pydata/xarray/issues/1288,283158736,MDEyOklzc3VlQ29tbWVudDI4MzE1ODczNg==,221526,2017-02-28T21:00:30Z,2017-02-28T21:00:30Z,CONTRIBUTOR,"👍  for the functionality (both `intergrate` and `gradient`) that work with `DataArray`. My concern is that this doesn't feel like functionality that inherently belongs as a *method* on a `DataArray`--if doesn't *need* to be a method, it shouldn't be. In numpy and scipy, these are separate functions and I think they work fine that way.

Another way to look at it is that methods are there to encapsulate some kind of manipulation of internal state or to ensure that some kind of invariant is maintained. I don't see how `integrate` is doing any of this for `DataArray`--seems like everything `integrate` would do would be doing can be accomplished using the public API. So really what you're buying is doing this:
```python
da.integrate(dim='x', method='trapezoidal')
```
instead of
```python
integrate(da, dim='x', method='trapezoidal`)
```
If you want to see what the pathological case of putting everything as a method for convenience looks like, go look at all the plot methods on matplotlib's `Axes` class. Pay special attention to the tangled web of stuff that comes from having ready access to the class's internals.

My real preference would just to have this work:
```python
ds = xr.tutorial.load_dataset('rasm')
np.trapz(ds['Tair'], axis='x')
```
but I have no idea what that would take, so I'm perfectly fine with xarray gaining its own implementation.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,210704949