It’s perfectly fine. It does mean, however, that numbers with a fractional part are stored using the Python float type, which does not have any specific number of fractional digits. The fractional point “floats” as needed, hence the name.
Furthermore, float is not decimal. It is binary. So the only fractions that are exact are negative powers of two (0.5, 0.25, 0.125, etc.) or whole-number multiples thereof. Everything else is as close as the format allows, which means that it is very slightly off from the input value, in the database, and everywhere else.
This effect is not limited to Python. Python is using an industry-standard binary number format. This format is actually supported at the hardware level, for speed, on most modern equipment. Numbers in this format are stored in binary, for maximum precision, and converted back to decimal for display. (And converted from decimal, for computation and storage.)
Where the converted decimal number ends in all trailing zeroes, and in the absence of more specific instructions, Python typically “cleans up” the result by omitting the trailing zeroes. (You will see this when someone enters a value ending in .50; which will display as “.5”, not “.50”.)
But once in a while, that tiny discrepancy at the very tail end rounds the final decimal digit up or down, so the trailing digits are not quite all zeroes.
What happens to the occasional “offending” digit is up to the specific program. Some programs will compensate for it one way, others another, and others not at all. You’re seeing just that kind of disagreement here. Data Tables are compensating, while the Data Grid components are not.
For your own display, you know that the numbers are good to exactly two decimal places, no more. In that case, you should probably ask your Python code to display specifically to that many places, and no more than that.
