enthought
Partially dynamic Range traits not recognised as dynamic.
Some part-dynamic Range traits don't work correctly. The following definition raises a ValueError at class-creation time:
>>> class A(HasTraits):
... low = Int(0)
... value = Int(3)
... r = Range(value='value', low='low', high=10.0)
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 4, in A
File "/Users/mdickinson/.edm/envs/resist/lib/python2.7/site-packages/traits/trait_types.py", line 1693, in __init__
low = float( low )
ValueError: could not convert string to float: low
The example works if 10.0 is replaced with 10, and also works if the roles of low and high are reversed. The cause is that the value-type inference code here is doing the wrong thing in the case where high is a float and low is a string.
It's possible that the intent here is that if either of low or high is dynamic, then both should be.
Yeah, it's a known (to some) design flaw. I usually have a _zero = Constant(0.0) trait or whatever for such cases. It's working as designed; it's just a bad design, so I'd mark this as a feature request.
A variant on this bug: here we're attempting a dynamic default value, but that fails if neither the low nor the high is dynamic:
>>> from traits.api import *
>>> class A(HasTraits):
... foo = Range(0.0, 100.0, "bob")
... bob = Float(23.0)
...
>>> a = A()
>>> a.foo
'bob'
>>> class A(HasTraits):
... foo = Range(0.0, "high", "bob")
... bob = Float(23.0)
... high = Float(100.0)
...
>>> a = A()
>>> a.foo
23.0
Adding the bug label back: the ValueError originally reported can't possibly be intentional. If it was the design intent that static low + dynamic high is okay but dynamic low + static high is not (unless high is an int rather than a float), then the not-okay case should be raising TraitError with a clear message rather than ValueError.
