[widget Audit] toga.NumberInput

[freakboy3742]

Audit of the Numberinput widget.

Builds on #1944.

Notable implementation details:

• Broadly, desktop platforms provided an up/down stepper; mobile platforms provide a numeric keypad.
• The min/max/step attributes are mostly managed on the interface side. This allows us to use Decimal as a representation (ensuring that we can round trip values); it also simplifies some of the implementation, as the widget becomes "text that can be interpreted numerically", with the interface performing final validation of that text. This is helpful because the number input needs to be in an invalid state a lot of the time (e.g., values that are outside min/max range)

Fixes #1455
Fixes #1234

Audit checklist

• Core tests ported to pytest
• Core tests at 100% coverage
• Core docstrings complete, and in Sphinx format
• Documentation complete and consistently formatted
• cocoa backend at 100% coverage
• winforms backend at 100% coverage
• gtk backend at 100% coverage
• iOS backend at 100% coverage
• android backend at 100% coverage
• Widget support table updated
• Widget Issue backlog reviewed

[freakboy3742]

@mhsmith This has now been rebased against the changes from #1944.

[mhsmith]

It doesn't look like #1455 has been fixed on Cocoa. After clicking Clear followed by the decrement button:

[freakboy3742]

It doesn't look like #1455 has been fixed on Cocoa. After clicking Clear followed by the decrement button:

Fixed (Again).

[freakboy3742]

Good point - but I guess my question is why HALF_UP rather than HALF_DOWN? I guess it doesn't really matter, as it's literally only the 1.500000000 case that matters - but HALF_DOWN would seem more consistent with the ROUND_DOWN in that case.

[mhsmith]

This only makes a difference when the app user manually enters a number that ends with a 5, so we should do whatever will confuse the smallest number of those users, who are likely not to have any advanced mathematics education.

ROUND_HALF_DOWN is not commonly used by anyone, so the real choice is between ROUND_HALF_UP (which I was taught in school), and ROUND_HALF_EVEN (which @freakboy3742 was taught in school).

ROUND_HALF_EVEN is used by the Python round function, and in most scientific contexts.

ROUND_HALF_UP is used by spreadsheets, and, based on my searches, in the majority of basic mathematics education, at least in English. For example, see "as taught in school" in the AppleScript documentation.

So I think we should go with ROUND_HALF_UP.

[freakboy3742]

That reasoning all makes sense to me. (also - lol at AppleScript having an actual "as taught in school" keyword....)

[freakboy3742]

This seems like it should be managed by subclassing, rather than probing attribute access.