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/3891#issuecomment-818377781,https://api.github.com/repos/pydata/xarray/issues/3891,818377781,MDEyOklzc3VlQ29tbWVudDgxODM3Nzc4MQ==,2448579,2021-04-13T02:07:22Z,2021-04-13T02:07:22Z,MEMBER,"> and to extend keep_attrs to accept a bool, a str or a function.
If we allow `keep_attrs` to be a custom function, then we could move towards some of the ideas in here: https://github.com/pydata/xarray/issues/988 . If that custom function received something like the `UfuncContext` in that issue, then an external library could implement data provenance handling like the `history` attribute, and set things like `cell_methods`. The context manager idea seems a little complex but doing something like
```
xr.set_options(keep_attrs=cf_xarray.attrs_handler)
```
could be OK, where all decisions are left up to the external package (here `cf_xarray`).
(Though what's stopping us from directly adding `cell_methods` attributes now for reductions, weighted, and coarsen?)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,587895591
https://github.com/pydata/xarray/issues/3891#issuecomment-773693380,https://api.github.com/repos/pydata/xarray/issues/3891,773693380,MDEyOklzc3VlQ29tbWVudDc3MzY5MzM4MA==,14808389,2021-02-05T00:25:16Z,2021-02-05T00:25:16Z,MEMBER,"if I remember correctly, we decided to allow passing a user-provided function to `combine_attrs` and to extend `keep_attrs` to accept a `bool`, a `str` or a function.
Something to keep in mind is that not all strategies make sense for operations that involve only a single variable, like `isnull`, but I guess for those all string options except `drop` mean ""keep the attributes"".","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,587895591
https://github.com/pydata/xarray/issues/3891#issuecomment-766953351,https://api.github.com/repos/pydata/xarray/issues/3891,766953351,MDEyOklzc3VlQ29tbWVudDc2Njk1MzM1MQ==,14808389,2021-01-25T16:51:00Z,2021-01-25T16:51:00Z,MEMBER,"I did not think this through carefully, but I wonder if we should extend `merge_attrs` to also take a function with a list of attrs as its only parameter and move towards something like `combine_attrs` instead of `keep_attrs`: setting `keep_attrs` seems to choose between `combine_attrs=""drop""` and `combine_attrs=""override""`.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,587895591
https://github.com/pydata/xarray/issues/3891#issuecomment-612522628,https://api.github.com/repos/pydata/xarray/issues/3891,612522628,MDEyOklzc3VlQ29tbWVudDYxMjUyMjYyOA==,1217238,2020-04-11T22:03:56Z,2020-04-11T22:03:56Z,MEMBER,"I think it would probably be OK to start propagating more `attrs` by default as a breaking change. There's no easy way to roll this out incrementally, and I doubt too many users are relying upon metadata _disappearing_ when they do xarray operations, given the somewhat inconsistent state of the current rules.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,587895591
https://github.com/pydata/xarray/issues/3891#issuecomment-612501095,https://api.github.com/repos/pydata/xarray/issues/3891,612501095,MDEyOklzc3VlQ29tbWVudDYxMjUwMTA5NQ==,5635139,2020-04-11T19:52:37Z,2020-04-11T19:52:37Z,MEMBER,"> > Would we want a deprecation warning on any operation with an attr?
>
> That would be almost every operation wouldn't it?
Right, anything involving an object with `attrs`... hence my reluctance. Do we think it's OK to do this on a major version without a warning?
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,587895591
https://github.com/pydata/xarray/issues/3891#issuecomment-612486735,https://api.github.com/repos/pydata/xarray/issues/3891,612486735,MDEyOklzc3VlQ29tbWVudDYxMjQ4NjczNQ==,35968931,2020-04-11T18:39:58Z,2020-04-11T18:39:58Z,MEMBER,"I'm trying to imagine what the approach that delegated the largest fraction of the work to an attrs-handling plugin would be. Would it be to give the attrs plugin the input, and the name of the function/method that was being called, and let the plugin completely decide the output attrs? Or would that be under-specified?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,587895591
https://github.com/pydata/xarray/issues/3891#issuecomment-612445784,https://api.github.com/repos/pydata/xarray/issues/3891,612445784,MDEyOklzc3VlQ29tbWVudDYxMjQ0NTc4NA==,35968931,2020-04-11T15:24:58Z,2020-04-11T15:25:22Z,MEMBER,"> For example, in an operation dividing one dataarray by another, if they both share an attr which has a __div__ method, we call that and put the returned value on the resulting dataarray.
I agree that this would be very powerful, and allow users to implement all the things they want (provenance, units handling etc.), but this also seems like a big undertaking. In order to have well-defined handling of attrs through operations like `merge`, `concat`, and ufuncs, wouldn't the attr-handling interface have to be almost as complicated as xarray's actual interface? Not saying we shouldn't do it, but what's the minimum set of attr-handling hooks that would have to be defined (and implemented and tested)?
Do you think it would be useful to get input from someone who actually wants this for a complex use case? I think the most hardcore one will be data provenance, because that (a) will need complicated underlying logic, (b) ideally needs to be pretty fault-tolerant, and (c) won't be made redundant by pint or duck-array integration. There was someone on #1614 who was asking about this IIRC.
> Would we want a deprecation warning on any operation with an attr?
That would be almost every operation wouldn't it?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,587895591
https://github.com/pydata/xarray/issues/3891#issuecomment-609830530,https://api.github.com/repos/pydata/xarray/issues/3891,609830530,MDEyOklzc3VlQ29tbWVudDYwOTgzMDUzMA==,5635139,2020-04-06T14:30:26Z,2020-04-06T14:30:26Z,MEMBER,"Great, thanks @TomNicholas , appreciate the thoughtful reply.
One thing we could do (NB: I don't think we should do this right now, but building on the points above as ideation) is to defer to the `attrs` themselves. For example, in an operation dividing one dataarray by another, if they both share an attr which has a `__div__` method, we call that and put the returned value on the resulting dataarray. That way, even ex-pint integration, `Unit('m')` / `Unit('s')` could evaluate to `Unit('m/s')`. And where units want to be dropped, they could use those methods to return `None`.
Re next steps on setting the default to be `True`, what are people's thoughts? Would we take a PR for 0.16? Would we want a deprecation warning on any operation with an attr?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,587895591
https://github.com/pydata/xarray/issues/3891#issuecomment-609481850,https://api.github.com/repos/pydata/xarray/issues/3891,609481850,MDEyOklzc3VlQ29tbWVudDYwOTQ4MTg1MA==,35968931,2020-04-05T20:59:36Z,2020-04-05T21:01:09Z,MEMBER,"I think this is a good question @max-sixty , and I have some opinions based on my experience with [xBOUT](https://github.com/boutproject/xBOUT).
Firstly I agree with you that for those users who use [xarray as a convenience wrapper](https://github.com/pydata/xarray/issues/988#issuecomment-243124532) or for whom it's [useful but not critical](https://github.com/pydata/xarray/issues/988#issuecomment-316393986) it makes more sense to keep attrs by default. ""Drop by default because otherwise they might become inconsistent with your data"" never really made sense to me, because if you care that much about attrs being consistent with data then you really need well-defined rules for how they are propagated in all cases, which we don't (yet) offer. In all other cases you would rather keep them and have to deal with the edge cases (which is why I wanted #2482 ).
As a concrete usage example of wanting to preserve attrs while not being overly-concerned if they sometimes get dropped: in xBOUT, our data requires carting around some [`regions` attributes](https://github.com/boutproject/xBOUT/pull/107) so that we know [how to plot it](https://github.com/boutproject/xBOUT/pull/34) later. One day this could maybe be handled by custom indexes in xBOUT, but there are probably other communities whose attrs requirements couldn't be.
After the casual wrapper case, the most important cases are:
- Units, which IMO becomes much less relevant once pint integration is complete,
- [Data provenance](https://github.com/pydata/xarray/issues/1614#issuecomment-397966050),
- [CF conventions](http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery#Highly_Recommended_Variable_Attributes)
- Other domain-specific types of grids (like the xBOUT case, or staggered grids etc.)
At the risk of repeating what's in #1614 , I would like to see some hybrid approach, which gives a simple global default along the lines of what @crusaderky suggests, but also allows a plugin which takes over and rigorously specifies the behaviour for the users who do care. Then we can [outsource the work](https://github.com/pydata/xarray/issues/2288) of the complex logic to e.g. the community that actually has to preserve CF conventions, or a separate data provenance package.
(Also I made a new `metadata` issue label for these discussions)","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,587895591
https://github.com/pydata/xarray/issues/3891#issuecomment-604665945,https://api.github.com/repos/pydata/xarray/issues/3891,604665945,MDEyOklzc3VlQ29tbWVudDYwNDY2NTk0NQ==,6213168,2020-03-26T20:24:23Z,2020-03-26T20:24:23Z,MEMBER,"@shoyer to me this it would make the most sense to do a union of the inputs:
- if a key is present only in one input, it goes to the output
- if a key is present in multiple inputs, always take the leftmost
Note how this would be different from how scalar coords are treated; scalar coords are discarded when they arrive from multiple inputs and are mismatched. The reason I don't think it's wise to do the same with attrs is that it could be uncontrollably expensive to compute equality, depending on what people loaded in them. I've personally seen them used as back-references to the whole application framework. Also there's no guarantee that they implement ``__eq__`` or that it returns a bool; e.g. you can't compare two data structures that somewhere inside contain numpy arrays.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,587895591
https://github.com/pydata/xarray/issues/3891#issuecomment-604659118,https://api.github.com/repos/pydata/xarray/issues/3891,604659118,MDEyOklzc3VlQ29tbWVudDYwNDY1OTExOA==,1217238,2020-03-26T20:09:59Z,2020-03-26T20:09:59Z,MEMBER,"See https://github.com/pydata/xarray/issues/1614 for related discussion.
I'm happy to set aside backwards compatibility concerns for now and ponder what the ideal policy would be. The original choices here were not made in a super careful way.
My longest-standing concern here is about units. One common use case for `attrs` is to mark the units of an array, and those aren't always preserved by naive arithmetic. But perhaps this is less of a concern now that you can use pint with xarray?
The other concern is how to combine `attrs` in operations that involve multiple arrays. Currently we just copy attrs from the first object, but that probably is not the most consistent (e.g., ideally arithmetic should be reflexive).","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,587895591
https://github.com/pydata/xarray/issues/3891#issuecomment-604445960,https://api.github.com/repos/pydata/xarray/issues/3891,604445960,MDEyOklzc3VlQ29tbWVudDYwNDQ0NTk2MA==,5635139,2020-03-26T13:57:47Z,2020-03-26T13:57:47Z,MEMBER,"> Why would you want a `.drop_attrs()` method? `.attrs.clear()` will do just fine.
Yes that's fine if people are happy with `.attrs.clear()`. A method that returns the dataset object is useful for ""fluent"" method chaining.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,587895591
https://github.com/pydata/xarray/issues/3891#issuecomment-604310958,https://api.github.com/repos/pydata/xarray/issues/3891,604310958,MDEyOklzc3VlQ29tbWVudDYwNDMxMDk1OA==,6213168,2020-03-26T09:03:50Z,2020-03-26T09:03:50Z,MEMBER,"Why would you want a ``.drop_attrs()`` method? ``.attrs.clear()`` will do just fine.
I fully agree we should keep attrs by default.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,587895591