[BUG] IMO, but no opinions? Uncle Tim? was: int(float(sys.maxint)) buglet ?

[Tim Peters]

[Bengt Richter]
> Peculiar boundary cases:
> 
> >>> 2.0**31-1.0
> 2147483647.0
> >>> int(2147483647.0)
> 2147483647L
> >>> int(2147483647L )
> 2147483647
> >>>
> >>> -2.0**31
> -2147483648.0
> >>> int(-2147483648.0)
> -2147483648L
> >>> int(-2147483648L )
> -2147483648
> 
> some kind of one-off error?

It would help if you were explicit about what you think "the error"
is.  I see a correct result in all cases there.

Is it just that sometimes

    int(a_float)

returns a Python long when

    int(a_long_with_the_same_value_as_that_float)

returns a Python int?  If so, that's not a bug -- there's no promise
anywhere, e.g., that Python will return an int whenever it's
physically possible to do so.

Python used to return a (short) int in all cases above, but that lead
to problems on some oddball systems.  See the comments for float_int()
in floatobject.c for more detail.  Slowing float_int() to avoid those
problems while returning a short int whenever physically possible is a
tradeoff I would oppose.