-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should standard attributes such as 'standard_name' always be present, even if their value is None? #478
Comments
Hi Bryan, making it behave like a "normal" Python attribute provides much more flexibility, and is, I think, less surprising. If it always returned sn = f.standard_name # assuming that it returns None if unset
if sn is None:
raise ValueError("create a nice message")
print(sn) If you want a default value, then why pin it down to sn = getattr(f, "standard_name", None)
sn = getattr(f, "standard_name", "time") The >>> f = cf.example_field(0)
>>> f.get_property("standard_name")
'specific_humidity'
>>> del f.standard_name # or f.del_property(...)
>>> f.get_property("standard_name")
Traceback
...
ValueError: 'Field' has no 'standard_name' property
>>> f.get_property("standard_name", None)
None
>>> f.get_property("standard_name", ValueError("My message"))
Traceback
...
ValueError: My message
>>> f.get_property("standard_name", NotImplementedError("why this type of error?"))
Traceback
...
NotImplementedError: why this type of error? Hope that makes sense. |
I was very careful to suggest that this should be the behaviour for the "standard" CF things (not everything, so this isn't a "normal" Python thing). So, if there is no standard_name, then the standard. name is I can't actually think of a use-case where this is not what you'd want to happen. What is the use-case where you'd want to have it unset, as opposed to None? It's just bizarre to force software to trap errors instead of handling what will be a very normal case using "the way we think" ... |
(But this is not a hill for me to die on.) |
Hi Bryan, perhaps it comes down to what you'd want |
I think a field always has the notion of a standard name, it does not always have the notion of an attribute called Fred, so I expect the behaviour of If we don't do this, then any code parsing fields for standard attributes has to to do |
Hi Bryan, A few unordered thoughts: One thing to consider is If we defaulted the attribute to Python users of any sort expect AttributeErrors from "missing" python object attributes. Cheers, |
Hi Bryan - the name is not part of the data model, put properties in general are, and a Field, and most other constructs, always has a "properties" dictionary, even if it is |
But a "standard_name" is a CF property. I agree wrt arbitrary properties, but this isn't arbitrary! The distinction is even clearly made in the CF-python documentation, e.g. https://cfpython.bitbucket.io/docs/latest/classes/cf.Variable.html where I'd argue that the things that are cf-properties should have value None, if they are not set. The rest should not exist and return a ValueError if accessed with no value. (I am hoping by updating this, rather than adding a new comment, this will hide here unseen til next week) |
If I have a field,
f
, which has no standard_name, thencurrently returns
Shouldn't the correct answer be
None
, and if not, why not?The text was updated successfully, but these errors were encountered: