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
At the moment a user can change the dtype or labels of a scheme, but this will not automatically update the related tables.
So we should make those attributes properties that return a copy and provide setter functions. BTW, you can add a setter function to a Python property, so a user should be able to do something like schemes['my-scheme'].labels[0] = 'a' if we want to allow for it.
The text was updated successfully, but these errors were encountered:
At some point we have introduced Scheme.replace_labels() to offer the user a safe way to replace labels. This does of course not solve the issue that a user might do schemes['my-scheme'].labels[0] = 'a' which is not safe. However, it is not straightforward to rename the attribute labels to e.g. _labels and instead introduce a property labels as in that case it would not be stored to YAML any longer. So I wonder if we should simply stick with Scheme.replace_labels() as the proper way to change labels, just like a user should e.g. not directly modified Table.df.
I agree now that we have Scheme.replace_labels() users should no longer be tempted to replace labels directly.
I would also propose to not do anything here.
I mark this issue as wontfix for now.
At the moment a user can change the dtype or labels of a scheme, but this will not automatically update the related tables.
So we should make those attributes properties that return a copy and provide setter functions. BTW, you can add a setter function to a Python property, so a user should be able to do something like
schemes['my-scheme'].labels[0] = 'a'
if we want to allow for it.The text was updated successfully, but these errors were encountered: