NumberInput.value vs int

[maratori]

In Lona 1.7 NumberInput was added to work with <input type="number">. It was undocumented because we may want to change it in the next release.

Now all properties (value, step, min, max) have Optional[float] type.

node = NumberInput(value=10, step=2)
assert node.value == 10
assert node.step == 2
assert type(node.value) is float
assert type(node.step) is float

Most users will work with whole numbers only. And they will have to convert int(node.value) each time. It seems reasonable to provide some builtin option to have int directly.

I did two failed attempts in #87. The first was to add separate IntNumberInput, the second is to determine type based on step. Both seem bad options. Why? In two words value inside browser can be float even if it is invalid (see details).

Let's add new read-only property NumberInput.int_value.

• It will raise exception if non-integers are valid (for example NumberInput(step=0.1).int_value)
• It will return int if current value is valid integer
• It will return None if current value is invalid (for example NumberInput(value=3, min=5).int_value is None and NumberInput(value=0.5, min=0, step=1).int_value is None)

If you see better options, you are welcome.

[fscherf]

@maratori I did some research on the browser side

• Even though the type of the input is number the value of input.value is always a string
• You can enter, and therefore send, invalid values, but the return value of input.checkValidity() is false then

NumberInput.value

I think it would be most consistent to copy the behavior of the browser at let NumberInput.value be a string. For easy handling we should add to_int() and to_float().

To have NumberInput.value return int by default would be very convenient though.
On html5 level there seems no way to distinguish between int and float. If we want that, we would have to reconsider a split into NumberInput and FloatNumberInput (or something like that) or a keyword for NumberInput like base_type=int.

NumberInput.valid

I am not completely sure about this property. We could let the browser send the return code of input.checkValidity() for each CHANGE event, but that only works for one direction and not when NumberInput.value is set by the view. Maybe we should add checks in the python code and ignore what the browser thinks is valid (?)

[fscherf]

@maratori I think you are right. Also it makes more sense for value to be a float than an int the longer i think about it. Last question: Should it be int_value or to_int() ?

[maratori]

I'm ok with both

[fscherf]

Do we need this in the first place? number.int_value is a one-liner, but int(number.int) too. You have to check valid before hand anyway, because number.int_value can be none

[maratori]

That's a great question. I'm not sure (some time ago :) Exactly because it can be None.
That's why I'm not pushing this idea anymore.

[fscherf]

:) ok, then let's just cut int_value for now, and agree on

NumberInput.raw_value -> str
NumberInput.value -> Optional[float]
NumberInput.valid -> bool