Bugs item #1673757, was opened at 2007-03-04 21:34
Message generated for change (Comment added) made by ericvsmith
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Eric V. Smith (ericvsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: string and unicode formatting are missing a test for "G"
Initial Comment:
In stringobject.c and unicodeobject.c, the formatting codes for 'e', 'E', 'f',
'F', 'g', and 'G' all get routed to formatfloat(). formatfloat() is
essentially identical in stringobject.c and unicodeobject.c.
'F' is mapped to 'f'. There is a test for excess precision for 'f' and 'g',
but not one for 'G'.
The "type == 'g'" test should be "(type == 'g' || type == 'G')".
I assume this bug is in 2.5 and 2.6 as well, although I haven't verified that,
yet.
----------------------------------------------------------------------
>Comment By: Eric V. Smith (ericvsmith)
Date: 2007-03-04 21:42
Message:
Logged In: YES
user_id=411198
Originator: YES
This is the correct behavior:
>>> '%200.200g' % 1.0
Traceback (most recent call last):
File "<stdin>", line 1, in ?
OverflowError: formatted float is too long (precision too large?)
But 'G' is handled differently:
>>> '%200.200G' % 1.0
'
1'
'G' should give the same OverflowError as 'g'.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
