A RangeEditor editing a Range trait will not use the trait's low and high settings

[nicolasap-dm]

Using qt (pyside6 6.2.3) with the latest traitsui release (7.4.3).

A RangeEditor that edits a Range trait will ignore the trait's low and high and will default to 0.0 - 1.0 instead:

from traits.api import HasStrictTraits, Range
from traitsui.api import View, Item, RangeEditor

class FixedRange(HasStrictTraits):
    a_range = Range(low=0, high=72, value=1)

    def default_traits_view(self):
        return View(
            Item("a_range", style="custom", editor=RangeEditor(mode="slider")),
            width=330, height=60,
            title="Editor will not inherit low/high"
        )

FixedRange().configure_traits()

^{(Expected: slider going from 0 to 72 instead of 0.0 to 1.0)}

The same happens with other modes ("spinner").

Known workaround: assign low and high manually.
Limitation: this is unfeasible if the Range trait uses extended trait names for low and high.

---

Addendum. I should also point out that if the RangeEditor is then used, it will likely generate invalid trait values (in this case, Range is validating to int because high, low and value are ints; RangeEditor however produces floats because it ignored these parameters).

It surprised me that the exception is displayed to the user with a dialog rather than with a "failed validation" color.

[corranwebster]

Digging into this a bit, if you just do Item("a_range", style="custom") without adding a RangeEditor things work as expected.

[nicolasap-dm]

That's true, although this syntax would not allow selecting any other mode than the default one (here it would be "slider")

Edit: Just learned that the Range trait also has mode!

[corranwebster]

Key things from the looking into this:

• observed behaviour isn't a regression (which is what I was worried about)
• nevertheless it's not good
• to fix it would require a fairly substantial refactoring of the RangeEditor
• there are deeper problems with the Range trait which would likely impact a proper fix (see eg. Value-changing getters on dynamic Trait types are problematic traits#1390)

So probably not going to fix this in the near-future.