PreferencesHelper sets *_items preference for List preferences

[notmatthancock]

Version info (although the same problem essentially exists with traits v6.0.0):

$ edm list | grep -P "apptools|traits "
apptools             4.5.0-5         enthought/free
traits               6.1.1-1         enthought/free

Here's a small example:

Initially, the preferences file contains:

# File: myprefs.ini
[my_section]
things = "['one', 'two']"

Then, we run a script that updates the things preference list:

from apptools.preferences.api import Preferences, PreferencesHelper
from traits.api import Int, List, Str

class MyHelper(PreferencesHelper):
    preferences_path = 'my_section'
    things = List(Str)

prefs = Preferences(filename='myprefs.ini')
helper = MyHelper(preferences=prefs)
helper.things.append('another thing!')
prefs.save()

After the script is run, the preferences file looks like:

# File: myprefs.ini
[my_section]
things = "['one', 'two']"
things_items = "TraitListEvent(index=2, removed=[], added=['another thing!'])"

As far as I can tell, the culprit is this block in the PreferencesHelper class:

apptools/apptools/preferences/preferences_helper.py

Lines 65 to 73 in 5a136f6

	def _anytrait_changed(self, trait_name, old, new):
	""" Static trait change handler. """
	# If we were the one that set the trait (because the underlying
	# preferences node changed) then do nothing.
	if self.preferences and self._is_preference_trait(trait_name):
	self.preferences.set('%s.%s' % (self._get_path(), trait_name), new)
	return

[rahulporuri]

As far as I can tell, the culprit is this block in the PreferencesHelper class:

I can reproduce this issue and ^ line of code is definitely the issue. Well, a major part of it. trait_name that changed is things_items event and not things list. I guess self._is_preference_trait(trait_name) should return False - with an additional check I guess for whether or not the trait is a container type.

@notmatthancock do you know if any of the other container types are supported? I suppose not given this issue/behavior.

[notmatthancock]

I guess self._is_preference_trait(trait_name) should return False - with an additional check I guess for whether or not the trait is a container type.

The expected behavior IMO would be that updating the list on the helper and saving the preferences updates the saved list. This would not occur if _is_preference_trait returned False for *_items.

do you know if any of the other container types are supported?

I haven't tried it explicitly, but I'd assume it would alsp occur for other cases (dict and so forth) where trait_name is actually {trait_name}_items.