ToggleButtons / _Selection .value in Python side != .value on js side

[maartenbreddels]

Say we have

toggle = ipywidgets.ToggleButtons(options=[("One", 1), ("Two", 2)])

Then clicking on 'One' will reflect that toggle.value == 1.
However, on the js side, value is actually "One", which messes things up if you use jslink.
The problem is I think in SelectView._updateOptions (https://github.com/ipython/ipywidgets/blob/master/jupyter-js-widgets/src/widget_selection.ts#L90)
Which uses _options_labels for both the label and the data.
My guess is that on the Python side, both _options_labels and _options_values in ipywidgets._Selection need sync=True as well.
I unfortunately cannot get the dev-install.sh to work, otherwise I might attempt a PR.

Snippet to reproduce the bug:

import ipywidgets
toggle = ipywidgets.ToggleButtons(options=[("One", 1), ("Two", 2)])
label = ipywidgets.Label()
ipywidgets.jslink((label, 'value'), (toggle, 'value'))
ipywidgets.VBox([toggle, label])

version info: Python3 / ipywidgets (6, 0, 0, 'beta9')

[jasongrout]

In order to have something we can sync across JSON, we encode the python .value attribute as its label. All communication happens back and forth with the label - the value never goes over the wire to javascript. Thus, the 'value' in Javascript is the label. That's the current design.

I agree it's confusing and not really ideal. What are you suggesting the value attribute should be on the javascript side?

[maartenbreddels]

But the Python's side value is 1, not 'One', so it it not consistent. If toggle.value == 1, I expect the js side to also have 1 as its value, not 'One'.

[jasongrout]

So here are several options:

1. we don't sync the python value over, we just sync the label, and deal with label on the JS side.
2. we make .value the label everywhere, and you just have to deal with the inconvenience of using a new .value_object or something in python, which is the actual object corresponding to the selected label.

[maartenbreddels]

Why not:

• sync over _options_labels and _options_values
• have a .value and .label

It does make sense from the point of view of embedding widgets using jslink. You want to have labels visible in the gui, and have them control values in other widgets, not deal with the labels.

[jasongrout]

Option 2 seems like a reasonable compromise. We could also open things up so that the labels could be any primitive JSON value (i.e., could be an int). That way it's still trivial to use Select([1,2,3]) without having to do .value_object.

[jasongrout]

The crucial thing here is that we can't sync over the _options_values since they are arbitrary python objects - no guarantee that they are JSONable.

[maartenbreddels]

Ah ok, I didn't know that. I assumed they were. I mean, that would even be more useful right, you can have the values be widgets, and control for instance which widget .
And as it is now, _options_labels is also synced, so whatever issue there is with syncing _options_values, it will already exist.

[jasongrout]

And as it is now, _options_labels is also synced, so whatever issue there is with syncing _options_values, it will already exist.

Not sure what you mean by this. The labels are strings, so they are able to be synced.

[maartenbreddels]

https://github.com/ipython/ipywidgets/blob/master/ipywidgets/widgets/widget_selection.py#L80 just a Tuple right?

[jasongrout]

Yes, but only because we can't say that it is a Tuple of strings (traitlets limitation). The docs clearly say: "The labels are the strings that will be
displayed in the UI, representing the actual Python choices, and should be
unique. If labels are not specified, they are generated from the values."

[maartenbreddels]

Ok, but do you see the potential benefit of having _options_values being for instance a list of widgets? Is there any limitation that would hamper implementing something like that. Even if that is not possible, having int's and string's is already really useful.

[SylvainCorlay]

Yes, but only because we can't say that it is a Tuple of strings (traitlets limitation).

I think that we can force the trait of the contained element.

[jasongrout]

_options_values already can be anything, including a list of widgets.

For option 2 above, we could open up labels to be any value that can be converted to a primitive JSON value. Then you could directly use .value if the labels are actually a list of ints, which technically is the label, but would be the actual value in this case too.

[jasongrout]

Yes, but only because we can't say that it is a Tuple of strings (traitlets limitation).

I think that we can force the trait of the contained element.

For variable-size tuples? Last I checked, giving types for tuple elements is done to make the tuple a fixed-sized typed record structure.