This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tuomas.suutari
Recipients eric.smith, ezio.melotti, mark.dickinson, martin.panter, rhettinger, serhiy.storchaka, skrah, tuomas.suutari
Date 2015-03-08.22:19:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAPXCX8D4sEtSGsT+aF4K75FF_nBBLN5BXe0e6mBx0qi-TGYOyA@mail.gmail.com>
In-reply-to <1425809206.06.0.586241626175.issue23602@psf.upfronthosting.co.za>
Content
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?
History
Date User Action Args
2015-03-08 22:19:19tuomas.suutarisetrecipients: + tuomas.suutari, rhettinger, mark.dickinson, eric.smith, ezio.melotti, skrah, martin.panter, serhiy.storchaka
2015-03-08 22:19:19tuomas.suutarilinkissue23602 messages
2015-03-08 22:19:19tuomas.suutaricreate