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, scoder, serhiy.storchaka, skrah, tuomas.suutari, wolma
Date 2015-03-29.16:20:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1427646062.42.0.130980711472.issue23602@psf.upfronthosting.co.za>
In-reply-to
Content
Thanks for the comments again!

I fixed the "format(F(4, 27), '.1f') -> 0.2" issue
Serhiy Storchaka reported. Fix for that was as simple as adding one to the precision the decimals are calculated in, but while adding test cases for that I realized two new things:

  (a) I don't want "f" specifier to mean "infinite" precision, but instead some predefined value. I chose 6.
  (b) How about rounding? I don't want the current decimal context to affect that, since it's not logical that formatting of Fractions depends on the decimal context.

The rounding thing made things harder, since there was no way to pass decimal context for Decimal.__format__ without changing the local context -- at least with the C implementation; the Python implementation (_pydecimal) provided nicer API with optional context keyword argument.  So I decided to unify the C and Py API's of Decimal.__format__ and add the keyword argument support to the C API too. This is done in this v4 of the patch.

There's no docs for the added Decimal.__format__ kwargs, since I want some comments on that change first.
History
Date User Action Args
2015-03-29 16:21:03tuomas.suutarisetrecipients: + tuomas.suutari, rhettinger, mark.dickinson, scoder, eric.smith, ezio.melotti, skrah, martin.panter, serhiy.storchaka, wolma
2015-03-29 16:21:02tuomas.suutarisetmessageid: <1427646062.42.0.130980711472.issue23602@psf.upfronthosting.co.za>
2015-03-29 16:21:02tuomas.suutarilinkissue23602 messages
2015-03-29 16:21:02tuomas.suutaricreate