made a minor fix to one of the widget examples

[jdavidheiser]

No description provided.

[takluyver]

I tried to check this, but I ran into #5499.

[jdavidheiser]

I updated the PR with a potential fix for #5499 - this is definitely a dictionary randomization issue, and I think it's cleanest to force the values update during init so that it precedes other possible changes.

[takluyver]

Thanks! Only question: should we be using kwargs.pop('values'), to save setting the traitlet twice?

@jdfreder , I've assigned this to you for a quick review.

[jdavidheiser]

My original pass at a fix actually did use kwargs.pop, but given my lack of knowledge about the traitlets framework, I was hesitant to suppress the passing of 'values' just in case something else was being done with it.

[takluyver]

I don't think so, but to be honest traitlets is rather black magic to me as well. @minrk would know better.

[minrk]

pop should be okay. All init does with kwargs is iterate and setattr, so if you are already handling that, it should be fine to prevent it happening a second time.

[jdfreder]

The code here looks good to me 👍 . I thought we had a problem with the validation firing before values was set before, and that we had fixed it, but it looks like I was wrong. Thanks for catching the typo too!

[takluyver]

Thanks. @jdavidheiser , do you want to change it back to pop(), and we'll merge this?

[jdavidheiser]

@jdfreder - was the previous issue with values getting set related to the thread locking? I couldn't find threading being used in a similar way anywhere else, so at first I actually thought this issue had something to do with threading, before I confirmed the kwargs randomization issue by running the code with PYTHONHASHSEED set to different values.

[jdfreder]

related to the thread locking

No, IIRC it was just impossible to construct a SelectionWidget with values set in the constructor.

[jdavidheiser]

yeah, sorry about that - serves me right for trying to rush something before dinner and make the code sloppy