[ python-Bugs-1153226 ] string interpolation breaks with %d and large float

SourceForge.net noreply at sourceforge.net
Thu Mar 17 13:21:29 CET 2005


Bugs item #1153226, was opened at 2005-02-28 05:10
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Thorne (jerub)
Assigned to: Nobody/Anonymous (nobody)
Summary: string interpolation breaks with %d and large float

Initial Comment:
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)

----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2005-03-17 12:21

Message:
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.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2005-03-02 00:42

Message:
Logged In: YES 
user_id=44345

Sorry, I got corn-fused and misinterpreted 2**50 as 2e50.


----------------------------------------------------------------------

Comment By: Stephen Thorne (jerub)
Date: 2005-03-01 23:53

Message:
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

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2005-03-01 15:38

Message:
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.


----------------------------------------------------------------------

Comment By: Stephen Thorne (jerub)
Date: 2005-03-01 13:21

Message:
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.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-03-01 06:36

Message:
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().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470


More information about the Python-bugs-list mailing list