[issue42429] Behavior of general (%g, :g) formatting inconsistent for decimal.Decimal
New submission from Chris Warrick :
When formatting decimal.Decimal using old-style formatting (%g), the output is
as short as possible, as expected. When using new-style formatting (str.format
or f-strings), the output uses the input precision. Floats behave correctly
with new-style formatting.
Python 3.9.0 (default, Oct 27 2020, 14:15:17)
[Clang 12.0.0 (clang-1200.0.32.21)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import decimal
>>> d1 = decimal.Decimal("1.000")
>>> d2 = decimal.Decimal("1.500")
>>> f1 = 1.0
>>> f2 = 1.5
>>> f"{d1:g} {f1:g}"
'1.000 1'
>>> f"{d2:g} {f2:g}"
'1.500 1.5'
>>> "%g %g" % (d1, f1)
'1 1'
>>> "%g %g" % (d2, f2)
'1.5 1.5'
--
components: Library (Lib)
messages: 381578
nosy: Kwpolska
priority: normal
severity: normal
status: open
title: Behavior of general (%g, :g) formatting inconsistent for decimal.Decimal
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue42429>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29724] Itertools docs propose a harmful “speedup” without any explanation
New submission from Chris Warrick: The itertools recipes list [0] ends with the following dubious advice: > Note, many of the above recipes can be optimized by replacing global lookups > with local variables defined as default values. For example, the dotproduct > recipe can be written as: > > def dotproduct(vec1, vec2, sum=sum, map=map, mul=operator.mul): > return sum(map(mul, vec1, vec2)) This is presented in the document without any explanation. It may confuse beginners into always doing it in their code (as evidenced in #python today), leading to unreadable code and function signatures. There is also no proof of there being a significant speed difference by using this “trick”. In my opinion, this should not be part of the documentation, or should provide proof that it can provide a real, noticeable speedup and is not premature optimization. (Added in [1] by Raymond Hettinger — added to nosy list) [0]: https://docs.python.org/3/library/itertools.html#itertools-recipes [1]: https://github.com/python/cpython/commit/fc91aa28fd8dad5280fd4d3a4747b5e08ee37ac0 -- assignee: docs@python components: Documentation messages: 289020 nosy: Kwpolska, docs@python, rhettinger priority: normal severity: normal status: open title: Itertools docs propose a harmful “speedup” without any explanation versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue29724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23057] [Windows] asyncio: support signal handlers on Windows (feature request)
Change by Chris Warrick : -- nosy: +Kwpolska ___ Python tracker <https://bugs.python.org/issue23057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29134] contextlib doc bug
Changes by Chris Warrick : -- nosy: +Kwpolska ___ Python tracker <http://bugs.python.org/issue29134> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
