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/1080#issuecomment-261200107,https://api.github.com/repos/pydata/xarray/issues/1080,261200107,MDEyOklzc3VlQ29tbWVudDI2MTIwMDEwNw==,941907,2016-11-17T09:41:18Z,2016-11-17T09:41:18Z,NONE,"Thank you for continuing this discussion even though you didn't agree with the initial proposal.
I have accepted and embraced option 3) as it is indeed about the cleanest and most readable option.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,187373423
https://github.com/pydata/xarray/issues/1080#issuecomment-260116620,https://api.github.com/repos/pydata/xarray/issues/1080,260116620,MDEyOklzc3VlQ29tbWVudDI2MDExNjYyMA==,941907,2016-11-12T11:28:02Z,2016-11-12T11:28:02Z,NONE,"> Code is read in text form more often than it is interactively explored.

Good point, in that case explicit namespacing indeed helps.

> 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.

A module-level namespace has nothing to do with the class namespace, but I see you try to tie them, which makes sense in relationship with the argument about reading code in text form. However, that may not be clear for Python programmers as those namespaces are not tied in reality, better mention it in the docs. BTW, if you are enforcing some specific style guide, please note that in the docs. And I hope you strike the right balance between style complacency and universality.

> 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).

My problem with non-functional paradigms lies more in the `apply`, `map`... paradigms which accessors don't fit into than thread safety.

> 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.

That is indeed a good alternative, just not sure my colleagues will like the transition from `sig.lowpass(0.2).multiply(3)` to `sig.pipe(xdsp.lowpass, 0.2).pipe(np.multiply, 3)`. A benefit of `pipe` is that methods can be tab-completed from namespaces (useful for interactive usage) and that any compatible function can be used, not just registered methods. Perhaps I will suggest `DataArray.__call__ = DataArray.pipe`  (maybe that could be added in `xarray` ? should I make an issue for that?) which would make it quite convenient to write only `sig(xdsp.lowpass, 0.2)(np.multiply, 3)` which is almost the same in terms of chars written and has quite clear syntax (calling a signal with a function argument applies the function to it).
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,187373423
https://github.com/pydata/xarray/issues/1080#issuecomment-258702758,https://api.github.com/repos/pydata/xarray/issues/1080,258702758,MDEyOklzc3VlQ29tbWVudDI1ODcwMjc1OA==,941907,2016-11-06T19:09:43Z,2016-11-06T19:09:43Z,NONE,"The namespace argument doesn't seem very convincing since you already implement many methods which may shadow variables (mean, diff). By limiting control of the namespace you make some uses somewhat inconvenient. If you want users to use DataArray as a general and universal and also extensible container, limiting its namespace goes against that. If they shadow vars by their methods, that's their decision to make.

While it may seem cleaner to have a stricter API, in real use cases users care more about convenient code access than where it came from. And when they look at the method object it will clearly tell them where it was defined. Python's introspection capabilities are powerful enough that users can find out such information.

What I meant by the 2. point was that in many cases one just needs a simple method and with the accessor approach one has to write extra lines of code like the ones you suggested earlier that may later seem cryptic. Caching of the accessor can be indeed useful, just not always. If you want people to develop plugins, make it as simple as possible and yet also advanced for those who require it. And then there""s also the problem of accessors not being usable in functional programming paradigms.

Tl;dr: accessors have benefits (namespace containment, caching) but also limitations (not functional paradigm, overkill sometimes). Give users more control over methods and you'll get more plugins.

On November 6, 2016 2:22:44 PM GMT+01:00, Stephan Hoyer notifications@github.com wrote:

> > 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 wrote 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.
> 
> ## 
> 
> You are receiving this because you authored the thread.
> Reply to this email directly or view it on GitHub:
> https://github.com/pydata/xarray/issues/1080#issuecomment-258680571

## 

Sent from my Android device with K-9 Mail. Please excuse my brevity.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,187373423
https://github.com/pydata/xarray/issues/1080#issuecomment-258623314,https://api.github.com/repos/pydata/xarray/issues/1080,258623314,MDEyOklzc3VlQ29tbWVudDI1ODYyMzMxNA==,941907,2016-11-05T16:41:07Z,2016-11-05T16:41:07Z,NONE,"Thank you for your response.

I still don't understand why you are pushing accessors in place of methods to such an extent. 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.

While the solutions you presented are usable, they seem like workarounds and somewhat redundant or add extra like overhead (in terms of writing code). Registering extra dataset accessors where DataArray method application would do seems again redundant.

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

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)
2. caching on the dataset sometimes makes no sense and just adds redundancy and complicates the design and registering of extra functionality

I'm not trying to say that the accessor approach is wrong, I'm sure it makes sense for certain plugins.  I'm just trying to share my experience with a very similar case where the simpler method approach turned out to be satisfactory and I think enabling it would increase the chances of more xarray plugins (which may not need accessor logic) coming to life.

Btw, perhaps it might be better to (perhaps optionally) issue a warning when overriding an existing class attribute during registering instead of completely refusing to do so.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,187373423