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
I recently had to completely disable trait notification during instantiation of a HasTraits child class. Holding with hold_trait_notifications wasn't sufficient; the notifications release when exiting the context manager was modifying attributes I didn't want to change.
I used a snippet found in the source code to implement the following context manager.
One relatively straightforward way to enable this behavior would be for hold_trait_notifications to yield the "cache" of notifications received during the context. Implementing a mute_trait_notifications method would then just involve calling cache.clear() before the context exited:
withobj.hold_trait_notifications() ascache:
... # do stuffcache.clear()
I'm not currently an active maintainer, but I don't think a change like this would be very controversial if you wanted to make a PR - very small and backwards compatible. We'd just want a test to ensure that future changes to hold_trait_notifications() don't break this expectation about being able to mute notifications.
I recently had to completely disable trait notification during instantiation of a
HasTraits
child class. Holding withhold_trait_notifications
wasn't sufficient; the notifications release when exiting the context manager was modifying attributes I didn't want to change.I used a snippet found in the source code to implement the following context manager.
Wondering if it would make sense to have this as part of the API. Hope I'm not suggesting an anti pattern 😅
The text was updated successfully, but these errors were encountered: