Skip to content
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

Fix use of _items as a normal trait in PreferencesHelper and PreferencesPage #226

Merged
merged 3 commits into from
Nov 23, 2020

Conversation

kitchoi
Copy link
Contributor

@kitchoi kitchoi commented Nov 19, 2020

Closes #225

This PR changes the listener for synchronizing the traits on the PreferencesHelper and PreferencesPage with the preferences, such that if the helper / page has a trait with a name suffix _items defined, it would not be mistaken as the event trait for list/set/dict mutation. Otherwise it would assume it is the event trait for list/set/dict mutation, and handle it specifically. If the assumption is wrong, the change handler will raise an error, but the error will be captured in a normal run condition and the default log message will appear.

This fix is possible because one cannot have a trait called name and a trait called name_items (not an event) and expect both of them to operate normally. Consider the following traits-only tests:

import unittest
from traits.api import *

class ItemsFirst(HasTraits):
    names_items = Str()
    names = List(Str)

class ItemsSecond(HasTraits):
    names = List(Str)
    names_items = Str()

class TestItems(unittest.TestCase):
    def test_mutate_fails_items_second(self):
        obj = ItemsSecond()
        obj.names_items = "Hello"
        obj.names = []
        with self.assertRaises(TraitError):
            obj.names.append("1")

    def test_assignment_fails(self):
        obj = ItemsFirst()
        obj.names = []
        obj.names.append("1")
        with self.assertRaises(TraitError):
            obj.names_items = "Hello"

The above tests pass. If there is a list called "names" and there is a trait called "names_items", the existence of the second trait will cause a lot of unexpected behaviours on its own already.

Checklist

  • Add a news fragment if this PR is news-worthy for end users. (see docs/releases/README.rst)

Copy link
Contributor

@aaronayres35 aaronayres35 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes LGTM.
The test that sparked my concern here: https://github.com/enthought/apptools/pull/196/files#r526423040 now passes as well. (This scenario covered by the tests added here).
Also this PR description is very clear as to why this fix is possible

Comment on lines 78 to 81
# If we were the one that set the trait (because the underlying
# preferences node changed) then do nothing.
if self._is_preference_trait(trait_name):
self.preferences.set("%s.%s" % (self._get_path(), trait_name), new)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do find this comment a little confusing... We are not conditionally doing nothing as it suggests

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I think I know what this means, but I agree this is not obvious at all, I will try to fix this comment.

@@ -90,6 +88,9 @@ def _anytrait_changed(self, trait_name, old, new):
getattr(self, trait_name)
)

# If the change refers to a trait defined on this class, then
# the trait is not a preference trait and we do nothing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is much clearer, thank you!

@kitchoi kitchoi merged commit 7cfe2f1 into master Nov 23, 2020
@kitchoi kitchoi deleted the 225-items-overload branch November 23, 2020 15:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

PreferencesHelper does not distinguish defined trait named "*_items" from _items event trait for listeners
2 participants