I browsed the issues to check whether there was an open issue on this, but didn't find anything.
Apologies if it is a duplicate.
I am an happy user of the new quantile method in xarray. I think though that creating a coordinate that has the same name as the method can raise issues.
While updating my code to switch entirely to xarray and the quantile method, I realized that this could be an issue. In the old code I had some datasets created using np.nanpercentiles, in which I had generated the coordinate and named it "q".
At some point in my code I have to retrieve the list of the q values, I used to do that by extracting the values:
x = ds.q.values
updating it to what would be the coordinate automatically generated by xarray, it should be
x = ds.quantile.values
But of course, when trying to call the coordinate "quantile" from the dataset, you get an Attribute Error:
AttributeError: 'function' object has no attribute 'values'
This can be easily solved by accessing the coordinate as:
x = ds['quantile'].values
However, I thought to point out that using the same name for the coordinate and the method can raise this type of issues.
I think that's right. While strictly the dict lookup is more robust, we should at least attempt not to cause a conflict there
At one point we were discussion discouraging, if not deprecating, the attribute style access of variables. I can't seem to find that issue now though...
we were discussion discouraging, if not deprecating, the attribute style access of variables
I guess this came up with .transpose() and .T: https://github.com/pydata/xarray/pull/1643 , https://github.com/pydata/xarray/issues/1232
Any ideas for an alternative dimension name?
quantiles with an s?
percentile ?
percentile / quantile_dim?
I suppose another choice would be to make this entirely explicit in the future, e.g,. require passing in quantiles as a 1D xarray.DataArray or pandas.Index. I don't know if that would really make people happier.
(short introduction: I created this issue, but I didn't realize I was logged in into another account)
I am not sure I have a constructive comment on how to name it.
If the future version will deprecate the attribute style access, I can see how it won't be a problem eventually, but I though to open this issue to bring it up.
how about just "q", since that is the name of the parameter? too short?
In order to maintain a list of currently relevant issues, we mark issues as stale after a period of inactivity
If this issue remains relevant, please comment here or remove the stale label; otherwise it will be marked as closed automatically