[issue23460] Decimals do not obey ':g' exponential notation formatting rules
Tuomas Suutari added the comment: > What is the status of this issue? I can submit a PR based on Tuomas Suutari's > patch. Don't know more about the status, but nobody seemed to care to take my patch forward. If contributions are accepted as GitHub pull requests these days, I can do it myself too. -- ___ Python tracker <https://bugs.python.org/issue23460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23602] Implement __format__ for Fraction
Tuomas Suutari added the comment: 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? -- ___ Python tracker <http://bugs.python.org/issue23602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23602] Implement __format__ for Fraction
Tuomas Suutari added the comment: On 29 March 2015 at 19:54, Serhiy Storchaka wrote: > I think that Decimal is not needed for Fraction.__format__ (and I'm not sure > that issue23602v4.patch is correct). Of course it's not needed. I'm using it to avoid re-implementing all the various formatting variations that can be controlled with the fill/align/sign/width/,/precision/type parameters (https://docs.python.org/3/library/string.html#formatspec). IMHO those should be supported as they are with floats and Decimals. > The correct way to format Fraction as fixed-precision decimal is to use > Fraction.__round__() or similar algorithm. The implementation can look like: > > f = self.__round__(prec) > i = int(f) > return '%d.%0*d' % (i, prec, abs(f - i) * 10**prec) Why this would be more correct than delegating the rounding (and formatting) to Decimal.__format__? (Then we just have to make sure that we have enough precision in the decimal context we're operating in. That's what I got wrong in the previous round.) -- ___ Python tracker <http://bugs.python.org/issue23602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23602] Implement __format__ for Fraction
Tuomas Suutari added the comment: 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. -- Added file: http://bugs.python.org/file38728/issue23602v4.patch ___ Python tracker <http://bugs.python.org/issue23602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23602] Implement __format__ for Fraction
Tuomas Suutari added the comment: Version 3 of the patch. Changes to v2: * Use raw-strings for the regexps. * Make the specifier regexp more robust with \A, \Z and re.DOTALL. * Add more test cases; especially g and e formats and negative fractions. -- Added file: http://bugs.python.org/file38413/issue23602v3.patch ___ Python tracker <http://bugs.python.org/issue23602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23602] Implement __format__ for Fraction
Tuomas Suutari added the comment: Martin Panter wrote: > Regarding sharing fractions._parse_format_specifier(), perhaps have a look at > _pydecimal._parse_format_specifier() I did find that, but since it was a private function in private module, I was unsure if I can use it here. The _pydecimal one parser also does more stuff that I need. -- ___ Python tracker <http://bugs.python.org/issue23602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23602] Implement __format__ for Fraction
Tuomas Suutari added the comment: Here's the next round of the patch. For formatting fractions with any given precision I had to parse the precision from format specifier and at this point it seemed easier to just create a general parser for the Format Specification Mini-Language. In this patch it is implemented in fractions._parse_format_specifier function, but maybe this kind of general function should be moved to better place and be documented and exported. What do you think? -- Added file: http://bugs.python.org/file38394/issue23602v2.patch ___ Python tracker <http://bugs.python.org/issue23602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23602] Implement __format__ for Fraction
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 <http://bugs.python.org/issue23602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23602] Implement __format__ for Fraction
Tuomas Suutari added the comment: Serhiy Storchaka wrote: >>>> from fractions import Fraction as F >>>> format(F(1, 3), '.30f') > '0.00' Good catch! I'll try to fix this and add some more test cases. -- ___ Python tracker <http://bugs.python.org/issue23602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23602] Implement __format__ for Fraction
Tuomas Suutari added the comment: Here's a patch that adds Fraction.__format__ implementation, test cases and documentation. -- keywords: +patch Added file: http://bugs.python.org/file38378/issue23602.patch ___ Python tracker <http://bugs.python.org/issue23602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23602] Implement __format__ for Fraction
New submission from Tuomas Suutari: Since Decimal supports __format__, it would be nice that Fraction did too. -- components: Library (Lib) messages: 237460 nosy: tuomas.suutari priority: normal severity: normal status: open title: Implement __format__ for Fraction versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue23602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23460] Decimals do not obey ':g' exponential notation formatting rules
Tuomas Suutari added the comment: Here's a patch that fixes the description for 'g' to explain what happens for `Decimal` and also documents the Decimal.__format__ in the documentation of the decimal module. -- keywords: +patch nosy: +Tuomas Suutari Added file: http://bugs.python.org/file38370/issue23460.patch ___ Python tracker <http://bugs.python.org/issue23460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22154] ZipFile.open context manager support
Tuomas Suutari added the comment: The context manager support was added on issue #5511, so the documentation should go to 2.7, 3.4 and default. Also the version added notes should be added. -- nosy: +Tuomas Suutari ___ Python tracker <http://bugs.python.org/issue22154> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com