Repository navigation
Value attribute differently named in odml and nixpy #308
Description
The Property.value accessor is differently named in odml (Property.value) and nixpy (Property.values).
Should we unify this to either of the attribute names? This would be a breaking change.
Reacted by Jan Grewe
Metadata
Metadata
Assignees
Labels
No labels
Activity
jgrewe commentedon Nov 6, 2018
I guess this should indeed be named in the same way. I am completely uncertain whether to favour
p.valueorp.values.This does not necessarily mean a breaking change, though, we could support both for a while and deprecate the one or the other.
JuliaSprenger commentedon Nov 6, 2018
I think
p.valuesis more intuitive because it is always a list being returned and never a single item.achilleas-k commentedon Nov 6, 2018
I was about to suggest making it
valueas it sounds (in my opinion) more general. My thinking was that even when it's multiple values, you can think of it as the value of this property is a list. @JuliaSprenger makes a good point though that even in single value cases, we return a tuple, sovaluessignals that we're returning some sort of iterable or collection.So I vote for
values.To @jgrewe's point, we could also keep both. Is there a good reason for deprecating one in the long run? I guess it might lead to some confusion. Two properties where one is an alias for the other isn't common so some may take it as a signal that there's a difference (unless they read the documentation). That said, I wouldn't be against having both without deprecating (any time soon).
mpsonntag commentedon Nov 6, 2018
I would vote for
p.valuesin odml and keepingp.valuewith a deprecation warning for the next year (or other arbitrary timeframe).[tools/dictparser] Proper 'values' handling on save