What's the role of keep_attrs?

[max-sixty]

I notice that keep_attrs has been the object of lots of work, and there are still some open issues — e.g. on a recent unrelated PR it was a lagging issue.

Can I ask a n00b question — as someone who doesn't use them much but sees the impact on the interface — why do we have this parameter is so many methods? Why not offer a .reset_attrs() method, similar to .reset_coords(), cut the parameter in each transformation — wouldn't that make the interface more orthogonal?

Is it that users would want to reset so often that this approach would litter use code with these calls? Or is it that we used to use attrs for units where dropping generally made sense, and then we added the functionality to keep them, and then it spread throughout the interface?

[keewis]

Or is it that we used to use attrs for units where dropping generally made sense

I think that's it, or in general that some operations would invalidate certain attributes (automatic physical unit propagation has come a long way in the past few years). It is true that it is more common to just globally set keep_attrs=True, so we might want to consider changing the default (see #3891, which you opened a long time ago).

We also (partially) changed keep_attrs to accept the names of builtin attrs merging functions and user functions (callables), which is important for operations that take more than a single variable. Though I guess in that case we could also just rename to combine_attrs.

[max-sixty]

(see #3891, which you opened a long time ago).

I was looking for this! I guess it doesn't show up for a search of keep_attrs in:title with an underscore...

[max-sixty]

OK, that makes a lot of sense.

I had two motivations:

• Having the popular setting be the default for users, which might well be having True here?
• Reducing the maintenance burden, by having a smaller API. But it sounds like there's actually some impressive logic in keep_attrs now, so it's not just a flag that almost everyone would want on.

I defer to you & the team on whether it'd be useful to switch the default...

[TomNicholas]

For context I originally started adding the keep_attrs kwarg in order to propagate units and grid information for xbout. It was one of the first things I added to xarray, and felt like a crutch even then. 😅 IIRC it was always intended to be used mainly via the global option.

I think in general it seems a lot of users with rich metadata (CF conventions + data provenance info especially) would often like to keep info that might be wrong in case it's useful. Xarray's metadata handling originally made the opposite assumption - that if we can't be sure the information is consistent it's best to drop it.

Why not offer a .reset_attrs() method, similar to .reset_coords(), cut the parameter in each transformation

I don't understand your suggestion here - are you suggesting that you drop the attrs, then use reset_attrs to re-add them at the end of your analysis?

I agree with @keewis that at least for the units motivation we now have better ways to handle the metadata.

EDIT: P.S. Also hey @max-sixty 👋 Haven't seen you here for a while! 😁

[max-sixty]

are you suggesting that you drop the attrs, then use reset_attrs to re-add them at the end of your analysis?

Sorry, maybe a drop_attrs method is a better way of saying it — i.e. rather than every method offering to keep or discard them, just allow a simple method to discard them

(Hello! Good to see you @TomNicholas ! It has indeed been a while...)

[max-sixty]

Down a level — on the reset vs drop point — I was thinking of reset_encoding as the corollary.

So possibly reset_encoding should be drop_encoding for consistency?