-
Notifications
You must be signed in to change notification settings - Fork 946
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document widget.observe(..., names) #3192
Comments
First of all thank you again for tackling that - it's definitely a weak point of the docs! The observe function is actually directly inherited from
ipywidgets/ipywidgets/widgets/widget_int.py Lines 81 to 82 in e0d41f6
all of these: ipywidgets/ipywidgets/widgets/widget_int.py Lines 158 to 169 in e0d41f6
and things like ipywidgets/ipywidgets/widgets/widget.py Lines 372 to 375 in e0d41f6
here is a (hopefully simple) example of how traitlets.All in observe works. Any trait that you add the class will be from traitlets import HasTraits, All, Int, Unicode
class widget(HasTraits):
# all attributes defined as traitlets like this will
# be included in traitlets.All
beep = Int(2)
boop = Unicode('blah blah')
_property_lock = Int(2) # this is just something defined by ipywidgets - nothing instrinsically special
def cb(change):
print(change)
obj = widget()
obj.observe(cb)
# property lock probably gets set on init
obj._property_lock = 0
obj.beep = 3
obj.boop = '2323'
# sometimes it gets updated along with a values
obj._property_lock = 2 To your specific questions:
If you look I think it gets updated anytime a trait that is synced to the frontend changes. So it's set once on init and again when you modify the value, hence two changes.
I think it essentially is - but a non-optimal default value to observe is sort of exposing it. I think that best practice to always explicitly use the
This is inherited from traitlets where All is probably a reasonable default because they have no idea how they will be used. I think there is an argument to be made that we should override
I have no idea what this does - something with syncing values behind the scenes maybe? |
Related issue: #1680 |
Is this an okay place to mention that the |
The documentation webpage is not connected to a live kernel. Copying that code into a notebook and running it should update the text. |
I am currently writing a documentation PR to add some examples to the
widget.observe
behaviour, and have come across some things that I need help clarifying. If anyone has anything enlightning, please stick it in this issue and I will incorporate it into a PR.Problem
widget.observe()
lets one specify what sort of widget "action" should trigger a function by using thenames
keyword. It's quite hard for the user to learn what sort of values to give it.By experimenting, I've found that generally the following output is generated with the default value of
traitlets.All
:It's not clear to me why
'_property_lock'
appears (twice!) in this output.Current accepted values include:
[traitlets.All, 'value', '_property_lock']
. Are there more?Suggested Improvement
names
and what they mean_property_lock
be a private name? It seems to be user-facing.names=traitlets.All
._property_lock
is - I would have guessed that it was some sort of "slider freezer" at first, but that doesn't quite add up with its value being a dict.The text was updated successfully, but these errors were encountered: