attributes no longer work like other components

I mean, you're in charge here, could you not provide dict-like behaviour AND the conveniences such as .addall()? You can create the object however you want!

The only reason I can see for not doing this¹ would be the Principle of Least Astonishment, if there are opportunities for confusion if we give the user something that quacks like a dictionary but is in fact something else.

I mean, you're in charge here, could you not provide dict-like behaviour AND the conveniences such as .addall()?

Yes, on reflection maybe I'm still missing a trick or two here.
It's clear that I do need a separate .attributes property, as here, so that when read it returns values instead of NcAttributes.
But on writing this could accept either -- which it currently does not.
And as you say, it could still usefully support add / addall for one or several NcAttributes.

Already, the NcData/NcVariable init methods are flexible in what you can pass to the 'attributes' : they detect whether you are passing dicts or lists of NcAttribute, or dicts of values + act appropriately. So we can be equally flexible here.

Update 2025-07-31

Now getting the house in order with completion of #118 and #116

Looking again at this, and recent traffic indicating there at least some users who may have an 'interest' in existing behaviour,
I'm just thinking again about the breaking-change aspects of this.

A less disruptive approach would be to avoid the rename of the existing .attributes --> ._attributes

Perhaps instead, we should leave <data/var>.attributes as it is,
and name the new "convenience" interface <data/var>.attrvals ?
(or just .attrs, or similar ?)

Also, on review, I am still a bit surprised about some of the existing behaviour, as even simple numeric values are returned as numpy array-scalars rather than 'pure' Python objects : So in that respect, as_python_value isn't really living up to the name.
So, perhaps that's another aspect we would do well to address in this 'new' interface.

Looking again at this, and recent traffic indicating there at least some users who may have an 'interest' in existing behaviour,
I'm just thinking again about the breaking-change aspects of this.

Again, you're in charge, so I'm not wedded to what I'm saying.

But I would argue that now is the time for breaking changes. Granted this might hurt some early users, but how many future users are going to get burned if the existing attributes remains there as a 'temptation'?

Looking again at this, and recent traffic indicating there at least some users who may have an 'interest' in existing behaviour,
I'm just thinking again about the breaking-change aspects of this.

Again, you're in charge, so I'm not wedded to what I'm saying.

But I would argue that now is the time for breaking changes. Granted this might hurt some early users, but how many future users are going to get burned if the existing attributes remains there as a 'temptation'?

There's never one simple answer to this question !

Ping @valeriupredoi @schlunma : you've shown the most active external-contributor interest here so far.
Do you have any suggestions on how disruptive it may be right now, to make breaking behaviour/api changes ?

There are not too many uses of ncdata in our code base right now, and as far as I can tell we are not using attributes anywhere. So my guess is that breaking changes regarding those attributes would not affect us.

However, to be extra safe, it would be helpful if you release a new version with the breaking changes before the end of August before our next release, so we could fix any problems before that. This will be our first release that includes ncdata, so past releases would not be affected.

... it would be helpful if you release a new version with the breaking changes before the end of August before our next release, so we could fix any problems before that. This will be our first release that includes ncdata, so past releases would not be affected.

Thanks, that's really useful !

OK I've had a slight change of heart on this now, which actually makes things simpler.
Hence 2b228d3, which changes the naming scheme.

In short, the proposal here now has a thing.attributes and thing.attrvals : both of these are public and supported.
But I am still deprecating set/get_attrval methods, as the ".attrvals" approach is equivalent but much nicer.

So, I came to the conclusion that

1. the new scheme needed a name less easily confusable, and
2. the ".attributes" is still useful as it is --
   e.g. for things like the ".addall" and ".update" mechanisms,

But I do expect that users will use attrvals in preference most of the time, and will be advising that.
TODO: extensive documentation updates are now called for. Watch this space ...

From the effects seen in changed files, I think it's clear that the new mechanism does make a lot of operations look neater and more natural. Not least, a whole lot of sources no longer have to import 'NcAttribute'.
So thanks @trexfeathers for pushing me on this !

TODO

• revise all docs to reflect
• AttrvalsDict
  • support assignment with NcAttribute in place of values
  • ensure complete test coverage, including the previous.
  • consider whether to allow add/addall (with NcAttributes), as mirror of .attributes property
    • .... or is "update" the more appropriate solution here?
  • add specific section explaining uses + differences of .attrvals and .attributes

Nearly there!

Still to do

• resolve what "copy" should do for AttrvalsDict, and provide one
  • if necessary, consider NameMap.copy also
• Add whatsnew
• make sure description of purpose is adequate