issue_comments: 612445784

This data as json

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