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: Add alternate float formatting styles to new-style formatting.
Type: enhancement Stage: resolved
Components: Interpreter Core, Library (Lib) Versions: Python 3.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: eric.smith Nosy List: Seungbeom Kim, eric.araujo, eric.smith, ezio.melotti, mark.dickinson, rhettinger, skrah, terry.reedy
Priority: normal Keywords: patch

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

Files
File name Uploaded Description Edit
issue7094.diff eric.smith, 2010-11-21 19:08 review
Messages (21)
msg93807 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-10-09 19:54
Python's old-style formatting supports the use of an alternative form 
(specified by including a '#' in the format) for 'e', 'f' and 'g' 
formatting:

Python 3.2a0 (py3k:75275:75276, Oct  7 2009, 20:26:36) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> '%.17g' % 1.2
'1.2'
>>> '%#.17g' % 1.2
'1.2000000000000000'

New-style formatting doesn't currently support this:

>>> format(1.2, '#.17g')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Alternate form (#) not allowed in float format specifier

To aid migration from old-style to new-style formatting, it might be worth 
adding the alternate forms.  At least the float, complex and Decimal types 
would be affected.
msg93808 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2009-10-09 19:58
I'm adding 2.7. Since 2.7 and 3.2 share the same code base, I'd rather
add it to both if we're going to do it at all.
msg93809 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-10-09 20:04
Just for reference, the effect of the alternative style is explained 
succinctly in the C99 standard (well, the N1256 draft, anyway):

"For a, A, e, E, f, F, g, and G conversions, the result of converting a 
floating-point number always contains a decimal-point character, even if 
no digits follow it. (Normally, a decimal-point character appears in the 
result of these conversions only if a digit follows it.) For g and G 
conversions, trailing zeros are not removed from the result. For other 
conversions, the behavior is undefined."
msg95913 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2009-12-02 17:44
When and if this is implemented, there's a test in test_float.py that
needs to be deleted. Search on "if not '#' in fmt:", added in r76632.
msg113442 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-08-09 18:36
I believe this is covered by the PEP3003 3.2 change moratorium.
msg113623 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-08-11 19:55
I do not believe that this is covered by the moratorium.  It's important for 3.x success to get new string formatting to its highest state of usability.  Matching published standards and practices(i.e. C99) and improving ability to convert from old-style to new style are both very helpful in this regard.
msg121760 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2010-11-20 20:32
Also note that if # is added for float and Decimal, it should be added for complex. My Bug Day sprint group will have a patch for this shortly.
msg121828 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2010-11-21 01:39
This is the patch developed today at the DCPython sprint. I have not reviewed it very well. I know that at least:
- formatting is not consistent
- the docs need reviewing
- I want to add more tests
- Misc/NEWS and Misc/ACKS need updating

But I'm uploading it here anyway so that it doesn't get lost. I'll be refining the patch over the next several days. The patch covers float, complex, and decimal.

Thanks to:
Eric Groo
Vlad Korolev
Bob Schmertz
Owen Martin
msg121963 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2010-11-21 19:08
Updated patch. I'm pretty happy with this one and will commit it after review.
msg121969 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-11-21 19:26
I haven't done a full review, but this looks good at first glance.

For '#g' formatting on the Decimal type, I wonder whether the patch gives the right semantics.  E.g., should

   format(Decimal('1.23'), '#.6g')

give '1.23' or '1.23000'?  For the float type, the '#.<precision>g' formatting has the property that <precision> digits are always returned, and I think this may be what we want here.  I'm not sure, though.
msg121970 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-11-21 19:31
I think the change below is sufficient if we decide that the '#g' formatting should always have the given number of significant digits.

--- Lib/decimal.py      (revision 86635)
+++ Lib/decimal.py      (working copy)
@@ -3701,7 +3701,8 @@
                 self = self._round(precision+1, rounding)
             elif spec['type'] in 'fF%':
                 self = self._rescale(-precision, rounding)
-            elif spec['type'] in 'gG' and len(self._int) > precision:
+            elif spec['type'] in 'gG' and (len(self._int) > precision or
+                                           spec['alt']):
                 self = self._round(precision, rounding)
         # special case: zeros with a positive exponent can't be
         # represented in fixed point; rescale them to 0e0.
msg121971 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-11-21 19:43
Gah.  That doesn't work for zeros, though.

Apart from this, the rest of the patch looks good, and all tests pass on my machine.  (Well, except for test_urllib2_localnet, but I'm pretty sure that failure is unrelated.)

I hadn't realized the use_alt_formatting stuff was already present in Python/pystrtod.c.
msg121992 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2010-11-21 21:10
I didn't realize it either, or I would have done this patch months ago. But of course it's needed for %-formatting.

I'll consider the 'g' case and see what I come up with.
msg122012 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2010-11-21 22:54
I agree that:
   format(Decimal('1.23'), '#.6g')
should give '1.23000', just as:
   format(1.23, '#.6g')
does.

I'll work on fixing the patch, although if I don't get to it in the next few days I'll commit the existing patch and open another issue, just to make sure this gets in before the beta.
msg122375 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2010-11-25 16:09
Checked in r86751. I'm leaving this open until I fix the remaining issue with '#g' for Decimal.
msg185760 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2013-04-01 19:04
@Eric looks as if the bulk of the work has been done so would you like to dot the i's and cross the t's?
msg218962 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2014-05-23 11:30
This might be out of date: _decimal has never implemented alternate
formatting and so far there have been no reported issues.

Another data point: Go apparently implements alternate formatting
only for octal, hex and strings:

http://golang.org/pkg/fmt/


So I'm unsure if anyone is actually using alternate formatting.
I think complaints about 2-to-3 porting problems should have
surfaced by now.
msg219016 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2014-05-24 00:49
> So I'm unsure if anyone is actually using alternate formatting.

That makes sense.  Any further effort should wait until there is known demand.  Otherwise, we risk growing the API with codes that aren't used.
msg219065 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2014-05-24 23:31
I'm going to go ahead and close this. Alternate formatting was added to float and complex. I think leaving this issue open just confuses whether or not that support was added. I know I had to go back and double check.

Since decimal never participated in %-formatting, there are no "migration to .format()" issues with it. I agree that it's unlikely anyone would want it, and if we want to add it, it would be a new, separate issue.
msg244428 - (view) Author: Seungbeom Kim (Seungbeom Kim) Date: 2015-05-29 22:38
It looks like this change has not been applied to Python 2.7. Do we have any chance of getting it to 2.7?

> So I'm unsure if anyone is actually using alternate formatting.

The "alternative form" is my favorite, and I think that "%#g" should be the default format for general floating-point values in numerical applications. That is why I miss this feature in Python 2.7 so much.
msg244432 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2015-05-30 00:21
New features only go in new versions.
History
Date User Action Args
2022-04-11 14:56:53adminsetgithub: 51343
2015-05-30 00:21:04terry.reedysetmessages: + msg244432
2015-05-29 22:38:14Seungbeom Kimsetnosy: + Seungbeom Kim
messages: + msg244428
2014-06-29 10:11:48ezio.melottisetstage: patch review -> resolved
2014-05-24 23:31:18eric.smithsetstatus: open -> closed
resolution: later -> fixed
messages: + msg219065
2014-05-24 00:49:50rhettingersetresolution: later
messages: + msg219016
versions: + Python 3.5, - Python 3.2
2014-05-23 11:30:44skrahsetmessages: + msg218962
2014-02-03 18:36:56BreamoreBoysetnosy: - BreamoreBoy
2013-04-01 19:04:54BreamoreBoysetnosy: + BreamoreBoy
messages: + msg185760
2012-01-23 15:18:19eric.smithlinkissue13838 superseder
2010-11-25 16:09:04eric.smithsetnosy: rhettinger, terry.reedy, mark.dickinson, eric.smith, ezio.melotti, eric.araujo, skrah
messages: + msg122375
components: + Library (Lib)
2010-11-23 14:37:12eric.smithsetstage: test needed -> patch review
2010-11-21 22:54:20eric.smithsetmessages: + msg122012
2010-11-21 21:10:01eric.smithsetmessages: + msg121992
2010-11-21 19:43:20mark.dickinsonsetmessages: + msg121971
2010-11-21 19:31:43mark.dickinsonsetmessages: + msg121970
2010-11-21 19:26:36mark.dickinsonsetmessages: + msg121969
2010-11-21 19:08:22eric.smithsetfiles: + issue7094.diff

messages: + msg121963
2010-11-21 19:07:56eric.smithsetfiles: - issue7094.diff
2010-11-21 01:42:28eric.araujosetnosy: + eric.araujo
2010-11-21 01:39:53eric.smithsetfiles: + issue7094.diff
keywords: + patch
messages: + msg121828
2010-11-20 20:32:11eric.smithsetmessages: + msg121760
2010-08-11 19:55:44rhettingersetnosy: + rhettinger

messages: + msg113623
versions: + Python 3.2, - Python 3.3
2010-08-09 18:36:05terry.reedysetnosy: + terry.reedy

messages: + msg113442
versions: + Python 3.3, - Python 2.7, Python 3.2
2010-03-05 01:55:24ezio.melottisetnosy: + ezio.melotti
2010-02-24 17:50:05eric.smithsetpriority: normal
2010-02-24 14:15:42skrahsetnosy: + skrah
2009-12-02 17:44:39eric.smithsetmessages: + msg95913
2009-10-09 20:04:17mark.dickinsonsetmessages: + msg93809
2009-10-09 19:58:08eric.smithsetassignee: eric.smith
messages: + msg93808
versions: + Python 2.7
2009-10-09 19:54:03mark.dickinsoncreate