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.

classification
Title: g formatting for decimal types should always strip trailing zeros.
Type: behavior Stage: needs patch
Components: Documentation Versions: Python 3.2, Python 3.3, Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: eric.smith, mark.dickinson, py.user, rhettinger, skrah
Priority: low Keywords: patch

Created on 2009-10-10 18:22 by mark.dickinson, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
issue7098.patch mark.dickinson, 2009-10-10 19:14 review
Messages (6)
msg93835 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-10-10 18:22
Type 'g' formatting for Decimal instances doesn't behave in the same way 
as for floats when an explicit precision is given.  It should strip all 
trailing zeros from the result:

Python 2.7a0 (trunk:75309, Oct 10 2009, 13:44:18) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal
>>> format(Decimal('123.00'), '.6g')  # expect '123'
'123.00'

(When no explicit precision is given, Decimal formatting with type 'g' 
tries to preserve the information about the exponent of the Decimal 
instance whenever possible;  this also differs from float formatting, but 
it's intentional.  This should probably be documented.)
msg93839 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-10-10 19:14
Here's a patch for trunk.
msg93840 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-10-10 19:28
> It should strip all trailing zeros from the result:

Hmm.  Thinking about this some more, I don't think this is true:  format() shouldn't be throwing away significant information (in Decimal 
the number of trailing zeros *is* significant information) unless that's 
necessary to fit the result into the given precision.

So I think the current code is correct.

However, we could do with documenting the precise rules being used for 
Decimal formatting somewhere.
msg150235 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2011-12-24 19:54
I would like to think about this one for a bit before it moves forward.
msg150629 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2012-01-04 18:35
[Mark]
> So I think the current code is correct.

I agree with this. Currently the 'g' format is like to_sci_string()
with the added possibility of adjusting the number of significant
digits. It's probably hard to come up with a better way to handle
this for Decimal.
msg174025 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2012-10-28 10:29
Closing as invalid.
History
Date User Action Args
2022-04-11 14:56:53adminsetgithub: 51347
2012-10-28 10:29:59mark.dickinsonsetstatus: open -> closed
resolution: not a bug
messages: + msg174025
2012-01-22 23:37:31py.usersetnosy: + py.user
2012-01-04 18:35:15skrahsetnosy: + skrah
messages: + msg150629
2011-12-24 19:54:47rhettingersetnosy: + rhettinger
messages: + msg150235
2011-12-24 19:22:24ezio.melottisetversions: + Python 3.3, - Python 2.6, Python 3.1
2009-11-28 15:19:58mark.dickinsonsetpriority: normal -> low
components: + Documentation, - Library (Lib)
stage: patch review -> needs patch
2009-10-10 19:28:51mark.dickinsonsetmessages: + msg93840
2009-10-10 19:14:48mark.dickinsonsetfiles: + issue7098.patch

nosy: + eric.smith
messages: + msg93839

keywords: + patch
stage: test needed -> patch review
2009-10-10 18:22:10mark.dickinsoncreate