Mark Dickinson added the comment: > Therefore, if I request 2 digits of precision, I expect 2 digits in the > output.
The `prec` attribute in the context refers to the total number of *significant digits* that are storable, and not to the number of digits after the decimal point. `Decimal` is at heart a floating-point type, not a fixed-point one (though the handling of significant zeros that you note means that it's useful in fixed-point contexts too). For typical uses you'll want `prec` to be much bigger than 2. So the number of trailing zeros is typically determined not by `prec` but by the exponents of the operands to any given operation. In the example you cite, the output is `2.50` because the inputs both had two digits after the point. > the docs assert that "Decimal numbers can be represented exactly" Sure, but for example the 0.1 in your code is not a Decimal: it's a Python float, represented under the hood in binary. Its exact value is 0.1000000000000000055511151231257827021181583404541015625, and that can't be stored exactly in a Decimal object with only two digits of precision. So the behaviour you identify isn't a bug: the module is following a deliberate design choice here. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20502> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
