Tuomas Suutari added the comment: Eric V. Smith wrote: > I'm not sure it needs fixing: it follows from the definition of using > Decimal(num) / Decimal(denom). Plus, it's controllable with a decimal context:
Hmm... Even though it's tempting to agree with you and just ignore the precision bug, but to be honest I have to agree with Martin Panter here. Depending on the current decimal context is not the way of "Least Surprise" when formatting Fractions. > For all of the tests, I suggest using format(value, str) instead of > ''.format(value). It more directly tests Fraction.__format__. I agree. Will change those. > In general I think adding Fraction.__format__ is a good idea, and I think > converting to Decimal is reasonable for the specified codes. My only question > is what to do when "natively" formatting Fractions themselves. We might want > to support field widths, padding, etc. Thanks! Actually I already tried to support field widths, padding and such. (See the test cases.) Or what do you mean? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23602> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
