Observe Traits Via Metadata

[rmorshea]

Allows the use of metadata as a way to observe traits

class A(HasTraits):
    foo = Int().tag(bar=True)

    @observe(tags={'bar':True})
    def _bar_observer(self, change):
        print 'change from bar tagged trait'

a = A()
a.foo = 1

For a more complete demonstration of the new features see test_traitlets.py:

• test_observe_decorator_via_tags
• test_observe_via_tags
• test_unobserve_via_tags

[minrk]

Needs tests for new functionality.

[ellisonbg]

I like this idea - it will help with certain patterns.

Question: does the example above mean that the bar field exists in the tags or has a value of True?

[SylvainCorlay]

👍

[SylvainCorlay]

It is a problem of argument pass-through. Since the corresponding call to HasTraits::traits in your example is traits(bar=True)... Since observe already takes keyword arguments, we cannot do the same and are forced to pass a dictionary.

[rmorshea]

Begs the question of whether 1ae7d72 is reasonable as well.

[SylvainCorlay]

If I understand this well, if names is All, then you end up listening to the "All" event and the filtered tags. I would rather compute a list of names from tags before calling parse_notifier_name.

[rmorshea]

48679e4 is a pretty drastic change, but it solves the problem of associating arbitrary notifiers with tags. Given that, I need to think on it to be sure it isn't fundamentally flawed, but feedback would be appreciated @SylvainCorlay, @minrk, @ellisonbg.

The gist of it:

• All notifiers are wrapped in EvenHandlers
• The _trait_notifiers and _trait_validators HasTraits attributes are lists instead of dicts.
• Collecting callbacks is done using the names and tags attrs on EventHandlers and requires this to be computed whenever _notify_change is called (this is because lists are used instead of dicts).

I have a feeling the _trait_notifiers and _trait_validators lists might slow down how quickly notifiers are called since collecting them isn't done via dictionary keys. If that's the case, dicts can be used (it just seemed redundant to have the name and type data in both the dict and on the EventHandler). With dicts though, having a helper function that flattens _trait_notifiers into a list might be convenient since the information can be present both ways.

[SylvainCorlay]

This is quite a big and non-trivial change. Can we work on pushing 4.1/5.0 first and get this in later? I am 👍 on the feature.

[ellisonbg]

+1 on waiting then

On Thu, Oct 22, 2015 at 10:44 AM, Sylvain Corlay notifications@github.com
wrote:

This is quite a big and non-trivial change. Can we work on pushing 4.1/5.0
first and get this in later? I am [image: 👍] on the feature.

—
Reply to this email directly or view it on GitHub
#111 (comment).

Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com

[rmorshea]

I've cleaned this up significantly and added a heuristic for triggering change types other than "change".

But yes, probably best to wait.

[rmorshea]

@minrk, @SylvainCorlay I think I've brought this to a point where it might be worth doing some review.

These changes are quite drastic in order to incorporate all the features that tags can (but perhaps shouldn't necessarily) introduce to observing to traits. To hide away some of the nastier heuristics and keep the main file as simple as possible, I created traitlets/utils/dict_types.py

For a more complete demonstration of the new features see test_traitlets.py:

• test_observe_decorator_via_tags
• test_observe_via_tags
• test_unobserve_via_tags

At this point, everything is included and functional, so we can trim features as we see fit.