Alexander Belopolsky
I accept that having math.floor() return an integer (and raise an exception for +-Inf) may be useful in many cases but it is different from the standard. Other floating-point libraries still return a floating-point value.
The standards are influenced by the limitation inherent in many languages where ints have finite range and cannot represent floor() of many finite floating point values. Python does not have this limitation. (Granted - PEP 3141 could do a better job explaining why floor, ceil, round, //, etc. should return Integer rather than Real.)
Scheme (which IIRC infuenced PEP-3141) has arbitrary precision ints, but guile at least returns floats: scheme@(guile-user)> (floor 2e308) $3 = +inf.0 [I'm mentioning Decimal now since the standard is *very* close to IEEE 754-2008.] Decimal's divide_int function returns "integers" (Decimals with exponent 0), but only if they don't overflow the context precision: c = getcontext()
c.prec 28 c.divide_int(Decimal("333e25"), 1) Decimal('3330000000000000000000000000')
c.divide_int(Decimal("333e250"), 1) decimal.InvalidOperation: quotient too large in //, % or divmod
Despite this fact, Decimal still returns inf in the disputed case:
c.divide_int(Decimal("inf"), 1) Decimal('Infinity')
Also, even when the Overflow trap is set, Decimal only raises Overflow when an operation actually overflows:
c.traps[Overflow] = True Decimal("1e999999999") * 10 decimal.Overflow: above Emax
Decimal("inf") * 10 Decimal('Infinity')
c.divide_int(Decimal("inf"), 1) Decimal('Infinity')
Stefan Krah