int(float) may return a long for no reason

[arigo]

BPO	11144
Nosy	@loewis, @arigo, @mdickinson
Files	issue11144.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/mdickinson'
closed_at = <Date 2011-03-26.12:31:42.917>
created_at = <Date 2011-02-07.17:45:54.752>
labels = ['interpreter-core', 'type-bug']
title = 'int(float) may return a long for no reason'
updated_at = <Date 2011-03-26.12:31:42.917>
user = 'https://github.com/arigo'

bugs.python.org fields:

activity = <Date 2011-03-26.12:31:42.917>
actor = 'mark.dickinson'
assignee = 'mark.dickinson'
closed = True
closed_date = <Date 2011-03-26.12:31:42.917>
closer = 'mark.dickinson'
components = ['Interpreter Core']
creation = <Date 2011-02-07.17:45:54.752>
creator = 'arigo'
dependencies = []
files = ['20724']
hgrepos = []
issue_num = 11144
keywords = ['patch']
message_count = 7.0
messages = ['128143', '128156', '128167', '128189', '128237', '128240', '132234']
nosy_count = 4.0
nosy_names = ['loewis', 'arigo', 'mark.dickinson', 'python-dev']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue11144'
versions = ['Python 2.7']

[arigo]

On 32 bits, there is no reason to get a 'long' here:

>>> int(float(sys.maxint))
2147483647L
>>> int(int(float(sys.maxint)))
2147483647
>>> int(float(-sys.maxint-1))
-2147483648L
>>> int(int(float(-sys.maxint-1)))
-2147483648

On 64 bits, it's another story because floats cannot store 64 bits of precision. However, -sys.maxint-1 can still be represented exactly in a float, and the same issue occurs:

>>> int(float(-sys.maxint-1))
-9223372036854775808L
>>> int(int(float(-sys.maxint-1)))
-9223372036854775808

[loewis]

I'm not sure whether this is a bug, though. So I'd be skeptical that it should be changed in 2.x, even if the cause was identified.

[mdickinson]

I'd call this a bug, albeit a minor one. The documentation for 'int' says:

"If the argument is outside the integer range a long object will be returned instead."

... which certainly suggests (without actually formally implying) that an int object should be returned if the argument is within the integer range.

[loewis]

I'd call this a bug, albeit a minor one. The documentation for 'int' says:

"If the argument is outside the integer range a long object will be returned instead."

Ah ok. I agree it's a bug, then.

[mdickinson]

This turns out to be a one-line fix (modulo comments and tests); see attached patch. The new code depends on the assumption that C longs are represented using two's complement, but note that this assumption is (a) already present elsewhere in the Python core (e.g., in the definition of bitwise operations for ints), and (b) universally true in practice (as far as I'm aware). For theoretical completeness, it would be easy to write a different test for ones' complement and sign-magnitude machines, but in practice that seems pointless, and given the near-impossibility of testing that code, I left it out.

[loewis]

Very smart!

[python-dev]

New changeset e1ebec2446cd by Mark Dickinson in branch '2.7':
Issue bpo-11144: Fix corner cases where float-to-int conversion unnecessarily returned a long.
http://hg.python.org/cpython/rev/e1ebec2446cd