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: string interpolation breaks with %d and large float
Type: Stage:
Components: Interpreter Core Versions:
process
Status: closed Resolution: duplicate
Dependencies: Superseder: "%d" format handling for long values
View: 1742669
Assigned To: Nosy List: arigo, jerub, josiahcarlson, mark.dickinson, skip.montanaro
Priority: normal Keywords:

Created on 2005-02-28 05:10 by jerub, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (8)
msg60684 - (view) Author: Stephen Thorne (jerub) * Date: 2005-02-28 05:10
We have experienced a problem recently when wanting to
render a large float as a string. Converting the float
to an int/long manuall was required. 

'%d' % f
throws an exception for all floats f, f >= 2**31

Expected output, shown with 'int()' and 'long()':
>>> '%d %d' % (long(float(2**31)), int(float(2**31)))
'2147483648 2147483648'

Non-Working Example.
>>> '%d' % float(2**31)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: int argument required

Tested on:
Python 2.3.4 (#1, Oct 26 2004, 16:42:40) 
Python 2.4.1a0 (#2, Feb  9 2005, 22:42:24)
msg60685 - (view) Author: Josiah Carlson (josiahcarlson) * (Python triager) Date: 2005-03-01 06:36
Logged In: YES 
user_id=341410

Note that it will also raise a TypeError when the float f, f
< -2**31

Is this a bug?  I don't know.  I tend to not pass floats
when string interpolation is expecting integers.  Maybe the
documentation should be cleared up.

If you really want a truncated float, perhaps "%.0f" is the
format you are looking for, to save you the effort of using
int() or long().
msg60686 - (view) Author: Stephen Thorne (jerub) * Date: 2005-03-01 13:21
Logged In: YES 
user_id=100823

My immediate reaction is, yes. This is a bug. 

Either floats should work with %d, or they should not at
all. Having a platform dependant upper bound on the size of
the float allowed is a bug.
msg60687 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2005-03-01 15:38
Logged In: YES 
user_id=44345

This is probably a corner case that got missed in the
int/long convergence.  Still, is there a reason not to use
%.f when you know you are passing a float and want to
display it with no fractional component?

>>> '%.f' % 2**50 
'1125899906842624'

or %ld if you expect the range to exceed the integer limits of
your hardware?

>>> '%ld' % 2**50
'1125899906842624'

I agree the documentation could probably be improved
in this area.
msg60688 - (view) Author: Stephen Thorne (jerub) * Date: 2005-03-01 23:53
Logged In: YES 
user_id=100823

%ld doesn't help. see the following example:

>>> "%.f" % float(2**31)
'2147483648'
>>> "%ld" % float(2**31)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: int argument required
msg60689 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2005-03-02 00:42
Logged In: YES 
user_id=44345

Sorry, I got corn-fused and misinterpreted 2**50 as 2e50.
msg60690 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2005-03-17 12:21
Logged In: YES 
user_id=4771

I am afraid that the same problem occurs all over the place, wherever long integers are accepted by built-in operations or functions.  Most of these places accept (and round) a float argument as well, though this is supposedly deprecated.  For example:

f = open('filename')
f.seek(999999999999)    # ok
f.seek(12.0)            # ok
f.seek(999999999999.0)  # OverflowError

Unless someone is willing to conduct a systematic review I believe it unlikely that it will get fixed, given the deprecation status.
msg61406 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-01-21 16:39
This is a duplicate of issue #1742669
History
Date User Action Args
2022-04-11 14:56:09adminsetgithub: 41633
2008-01-21 16:39:55mark.dickinsonsetstatus: open -> closed
resolution: duplicate
superseder: "%d" format handling for long values
messages: + msg61406
nosy: + mark.dickinson
2005-02-28 05:10:29jerubcreate