Thought made sense to post the PR as well, to see the proposed change to support this.

when extending to more complex or nested views it's rather inconvenient

Can you show an example that demonstrates the inconvenience? I think it would help in determining whether or not this is a necessary addition. At the moment we're trying to be conservative about adding new features to traitlets since there aren't that many people who maintain it.

Hi @rmorshea. So unfortunately I can't reference you to an actual example we have as it's proprietary. However to explain the situation we've now got models (economic instruments) that 50 or more different properties that we want to display.

This means that we have over 100 lines of replicating, redundant binding code (to define the variables then bind them as demonstrated below) on every view which is starting to make the code rather unreadable and losing focus from the key point we want developers to focus on, which is the view itself.

def view(model):
    a_view = widgets.FloatText()
    b_view = widgets.FloatText()
    ...
    z_view = widgets.FloatText()

    v = widgets.HBox([
        widgets.Label("Value A"),
        a_view,
        ...
        widgets.Label("Value Z"),
        z_view, 
    ])

    link((a_view, "value"), (model, "a"))
    link((b_view, "value"), (model, "b"))
    ...
    link((z_view, "value"), (model, "z"))
    return v

As I said, this is an inconvenience and the change does not introduce functionality which cannot already be achieved in a separate way (as demonstrated) but it does make for more concise and readable code when building this model/view paradigm.

Could this be solved with a utility function that can create more than one link at a time?

def link_many(source: Any, target: Any, attribute_mapping: Dict[str, str]): -> None: ...

Example usage:

link_many(
    source,
    target,
    {
        "source_attr_a": "target_attr_a",
        "source_attr_b", "target_attr_b",
    }
)

I bring this up because, while I do like the aesthetics of the SourceLink idea, I'd rather not impact TraitType.__set__ to do it if possible. traitlets already has some performance issues, so it'd be best to avoid incurring the cost of an extra isinstance(obj, SourceLink) check on every attribute assignment for a use case that is somewhat niche.