FloatRangeSlider value logic

[lheagy]

Update logic in setting of default value field of the FloatRangeSlider so that numpy arrays can be passed as inputs (see #2434). Note that this will still currently error in traitlets as a tuple is expected, but at least the error at this point is very clear: A trait error is raised:

TraitError: The 'value' trait of a FloatRangeSlider instance must be a tuple, but a value of class 'numpy.ndarray' (i.e. array([-5,  5])) was specified.

I would appreciate the ability to simply provide a 2-entry long numpy array in the value field. What do folks think of adding something like:

try:
    proposal_tuple = tuple(proposal['value'])
    proposal['value'] = proposal_tuple
except:
    raise TraitError

to the validation of the FloatRange value

ipywidgets/ipywidgets/widgets/widget_float.py

Lines 276 to 281 in 825dc58

	@validate('value')
	def _validate_value(self, proposal):
	lower, upper = proposal['value']
	if upper < lower:
	raise TraitError('setting lower > upper')
	return lower, upper

or would it make more sense to do something at the traitlets level?

[vidartf]

Currently, the container traits from traitlets have a whitelist of types they can cast from. I don't think we can use that system for adding support for numpy, as that would add a dependency on numpy. Simply casting to tuple should be ok though, since we are checking the type of the sub-elements (i.e. we will avoid a false positive for tuple('ok')). So unless someone else can think of some other false positives, I say the validate pattern you suggested should be ok.

[vidartf]

@jupyter-widgets/jupyter-widgets We should be able to merge this PR as is for the more helpful error message, and leave the other suggestions as future work for further discussion.

[SylvainCorlay]

Thanks! This looks good to me.