You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(I think this is a bug, else the documentation is not clear on the correct behaviour.) The documentation of the Conventions argument to cfdm.writepromises that:
By default the current conventions are always included, but if an older CF conventions is defined then this is used instead.
however when I write out a file specifying an older version of the Conventions, e.g. CF-1.6 using a CF-1.11 field and CF-1.11 version of cfdm as per the minimal example below (I tried with resetting that global attribute, also, with nothing changing frm that), it is read back in again with CF-1.11, which to me contradicts the second statement from the above promise - I would expect to see the Conventions property now being set to the older of the two, CF-1.6.
@davidhassell is the above behaviour incorrect, or am misunderstanding the documentation? In the former case we have a bug and in the latter an issue where the documentation is ambiguous or not clear, IMO.
(I haven't yet investigated why this might happen, mostly because I want to check the behaviour is indeed buggy in this way, but I wonder if the numbering of consecutive CF Conventions might be confusing the logic and need accounting for, since 1.11 comes after 1.6 in terms of versions but 1.6>1.11 numerically...)
sadielbartholomew
changed the title
Unexpected value for Conventions attr. after write setting older CF version
Unexpected Conventions attr. value after write setting older CF version
May 17, 2024
sadielbartholomew
changed the title
Unexpected Conventions attr. value after write setting older CF version
Unexpected Conventions attr. value after write setting older version
May 17, 2024
sadielbartholomew
changed the title
Unexpected Conventions attr. value after write setting older version
Unexpected attribute value after write setting older ConventionsMay 17, 2024
Hi Sadie - interesting. I'm not sure if the documentation is wrong (so not a code bug), or vice versa. In the latter case we'd have to check that the field being written out did not contain any features that were introduced post the specified version, which would be possible ...
By default the current conventions are always included, but if an older CF conventions is defined then this is used instead.
? I don't understand what 'if an older CF conventions is defined then this is used instead' is implying, if not what I mention I expect from it in my comment above.
(I think this is a bug, else the documentation is not clear on the correct behaviour.) The documentation of the
Conventions
argument tocfdm.write
promises that:however when I write out a file specifying an older version of the Conventions, e.g.
CF-1.6
using aCF-1.11
field andCF-1.11
version of cfdm as per the minimal example below (I tried with resetting that global attribute, also, with nothing changing frm that), it is read back in again withCF-1.11
, which to me contradicts the second statement from the above promise - I would expect to see theConventions
property now being set to the older of the two,CF-1.6
.@davidhassell is the above behaviour incorrect, or am misunderstanding the documentation? In the former case we have a bug and in the latter an issue where the documentation is ambiguous or not clear, IMO.
(I haven't yet investigated why this might happen, mostly because I want to check the behaviour is indeed buggy in this way, but I wonder if the numbering of consecutive CF Conventions might be confusing the logic and need accounting for, since 1.11 comes after 1.6 in terms of versions but 1.6>1.11 numerically...)
Minimal example
Environment
This is using the
main
branch ofcfdm
viapip
editable install) with:The text was updated successfully, but these errors were encountered: