I stumbled upon this when defining a preferences helper for a logging configuration.
When defining an Enum trait whose values contain strings that map to Python keywords or builtins (like the logging level "Warning"):
Upon initialization of the preferences, the _get_value method of the PreferencesHelper class, will call an eval on "Warning", which results in a type instance of Warning. The following Enum trait validator then fails since the Warning type in not contained in the enum.
When specifying the default preferences like this:
[application_logger]
default_level = "Warning"
works upon loading the first app startup.
But after closing the application, the user preferences are re-written, resulting in "Warning" being dumped without ticks.
A potential solution might be executing the "eval" and then dismissing results that are builtins?
Using apptools 5.1.0, traits 6.3.1, Win10
I stumbled upon this when defining a preferences helper for a logging configuration.
When defining an Enum trait whose values contain strings that map to Python keywords or builtins (like the logging level "Warning"):
Upon initialization of the preferences, the _get_value method of the PreferencesHelper class, will call an eval on "Warning", which results in a type instance of Warning. The following Enum trait validator then fails since the Warning type in not contained in the enum.
When specifying the default preferences like this:
works upon loading the first app startup.
But after closing the application, the user preferences are re-written, resulting in "Warning" being dumped without ticks.
A potential solution might be executing the "eval" and then dismissing results that are builtins?
Using apptools 5.1.0, traits 6.3.1, Win10