Message239664
| Author |
tuomas.suutari |
| Recipients |
eric.smith, ezio.melotti, mark.dickinson, martin.panter, rhettinger, scoder, serhiy.storchaka, skrah, tuomas.suutari, wolma |
| Date |
2015年03月31日.05:05:42 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<CAPXCX8DVy_p6rgsRWNGoRt4qXm+befwuXXm3=7H3Oi8=xM9=_w@mail.gmail.com> |
| In-reply-to |
<1427712582.38.0.692698903373.issue23602@psf.upfronthosting.co.za> |
| Content |
On 30 March 2015 at 13:49, Stefan Krah wrote:
> Regarding Decimal:
>
> 1) The context precision isn't used for formatting. If you have
> another reason for proposing the optional context argument for
> dec_format(), please open another issue.
Yes, context precision isn't, but context rounding mode is. That's why
I wanted to use a known context rather than the current (thread-local)
context.
But yes, I also thought that maybe the Decimal.__format__ changes
should go to another issue, which my implementation would then depend
on though. It wouldn't be too bad if Py and C version of
Decimal.__format__ had same interface. What do you think?
> 2) There's another problem: The mythical DefaultContext (which
> acts as a template for creating new contexts) affects not only
> new thread-local contexts, but also a new Context()!
>
> In my opinion this is something we should change: The mechanism
> is fine for thread-local contexts, but Context() should behave
> like a pure function.
I don't understand what do you mean with this. Is this something that
I'm doing wrong in my patch or just another (related?) issue?
> 3) The double rounding issues are more tricky than it might seem;
> if we use Decimal for this, perhaps direct support in the module
> would be the cleanest option.
What double rounding issues you're referring to? |
|