I'm considering a name different fromupdate_range() because if we want to later expand this toRangeSlider, thererange also has a dedicated and different meaning.

update_limits() would be good in terms of valmin, valmax, but is slightly worse in expressing that it also covers valstep. It would be nice if we could come up with something even better, but if not I would go withupdate_limits

range sounds more generic whereaslimits imply just upper and lower bounds.
The termrange should not clash withRangeSlider as it's a commonly used word when speaking about any slider.
Synonyms forrange are as follows:span,scope,scale,extent
Regardless, it's upto you to choose the name.
I choseupdate_range because that was suggested on theMatplotlib Discourse post.

The point is that "Range" in RangeSlider refers to the value range, whereas inset_range() it would refer to the definition range.
Using the same word for different aspects in the same context is confusing.

Oh, okay, yes, that's confusing. You can set the appropriate function name.

Semi-OT: While thinking about naming and howvalstep is integrated into that, I realized that we have some sloppy behavior / unclear definitions. We can have the following cases forvalstep:

• None - continuous slider [ok]
• number: stepped slider, basically atnp.arange(valmin, valmax, valstep) [ok]
• array_like: Explicitly giben values - these may be outside the interval [valmin, valmax] with surprising behavior: During operation via UI, the valstep values are effectively clipped by [valmin, valmax] because you can't move the handler past the limits. But you canset_val() to a valstep value outside the interval, in which case the slider button vanishes. There are also some other quirks already on initialization ifval, is not invalstep.

Overall, the interaction between val, array-like valstep and valmin/valmax is ill-defined.

Why is this relevant for this PR? Selective changes of valstep, valmin, valmax make this inconsistency worse. The way out of the inconsistency may affect the the way we specify the data range and thus how the API to modify must look like.

Edit: Additional issue: we cannot useset_range(...valstep=None) in the meaning "keep the existing value" becausevalstep=None is used to indicate a continuous range. - Preliminary way out: do not support "keep the existing value".

We can later add that behavior by using custom sentinels as default.

Edit: Ok the way forward is the following:

• Ifvalstep is array-like, we must raise a value error ifvalmin != valstep[0] or valmax == valstep[-1].
• Let's call the new functiondef set_limits(valmin, valmax, valstep=None). The continuous caseset_limits(vmin, vmax) is the default and reads good. If we stretch the "limit" interpreation from boundary to "limit the accepted values", also the inclusion ofvalstep makes sense.

Edit: Additional issue: we cannot useset_range(... valstep=None) in the meaning "keep the existing value" becausevalstep=None is used to indicate a continuous range. - Preliminary way out: do not support "keep the existing value".

vs.

Let's call the new functiondef set_limits(valmin, valmax, valstep=None)

I'm confused. Are we going withvalstep=None or just plainvalstep?
Also, why are the defaultNone values missing forvalmin andvalmax? Weren't they required to allow the user to set either one? (not everyone wants to set bothvalmin andvalmax simultaneously every time.

As an alternative, what are your thoughts on implementinggetter/setter properties instead?
Because even if we implement theset_limits() function,valmin,valmax, andvalstep are still accessible to be modified directly.

Whenvalstep is array-like and outside of thevalmin/valmax bounds, I cannot reproduce the slider vanishing. For example, forvalmin = 1 andvalmax = 10, I triedvalstep = [3, 5, 7] andvalstep = [0, 4, 8, 12]. The slider does not vanish.

But you're right that a check is required. About that,valmin != valstep[0] or valmax == valstep[-1] might not work, as thevalstep values can beunordered/non-sorted.
Even for unorderedvalstep, I see no issues when running it (I'm guessing this is intended behaviour?). But if we have to do the check, then maybe we should check againstsorted(valstep)?

Also, should there be a check forvalmin andvalmax too? Currently, even ifvalmin > valmax, the program runs, but the slider remains stuck. Is this intended?

Regarding the sentinel, some functions tend to use the'none' string to implyNone, leavingNone to be used as the sentinel itself, as intended. For example, theinterpolation parameter in theAxes.imshow function has 'none'(string) as one of its values, leaving the default toNone. (Reference)

Just a thought, maybe we could do the inverse and set 'none'(string) as the sentinel?
Or maybe set a global variable:SENTINEL = object() and use that instead?

Let's call the new functiondef set_limits(valmin, valmax, valstep=None)

I'm confused. Are we going withvalstep=None or just plainvalstep? Also, why are the defaultNone values missing forvalmin andvalmax? Weren't they required to allow the user to set either one? (not everyone wants to set bothvalmin andvalmax simultaneously every time.

valstep=None with the meaning of "no step". This maps the behavior from__init__, i.e. always set everything. The default is there since many sliders are not step-limited, so typingset_limits(valmin, valmax, valstep) would be awkward.

As an alternative, what are your thoughts on implementinggetter/setter properties instead? Because even if we implement theset_limits() function,valmin,valmax, andvalstep are still accessible to be modified directly.

We should possibly make the attributes private. Individual setters are not a good option. They are more cumbersome to useset_valmin(a); set_valmin(b) and there might be surprising interference with valmin, valmax and step if applied sequentially.

I think the boundary conditions for explict step values are not well thought through and not handled consistently. But the problem is not getting worse if we limit ourselves for now to the "always set everything" approach. As it is as good or bad as setting on__init___. We can then handle this topic later.

Yes, a sentinel object, would be the way to go. We have one here

def set_limits(valmin, valmax, valstep=None)`

to

def set_limits(valmin=_Unset, valmax_Unset, valstep=_Unset)`