[Tim]
int.__truediv__ makes semi-heroic efforts to get 10**400 / int(1e200) "right" (well, as right as can be)
[Stefan Pochmann <smpochmann@gmail.com>]
Yes, those semi-heroic efforts actually are what inspired my question. A few days ago I noticed that and was delighted it works.
Use case was the exact calculation of value around 8, for which I used fractions.Fraction. Numerator and denominator were large, but the division numerator/denominator still successfully provided a readable and right-as-can-be float.
So yes, even I who brought this up only noticed *that* semi-heroism after years of using Python,
I was similarly surprised that a Fraction instance with giant numerator and denominator converted to a float beautifully. That wasn't always so in Python .> and don't have an actual use case for the int-and-float division. The int/int
one just gave me the impression that Python is trying hard to give me results when possible, so I wondered about this case.
I believe there's something deeper at work with int / int: Python has long said that numeric values that compare equal have the same hash code, and can be used interchangeably as, e.g., dict keys. But if we're going to say that some Fraction f "is equal" to some float `x`,then surely Fraction(x) == f and float(f) == x should be true too. That's of real practical value, because it simplifies reasoning about code mixing floats and Fractions (and Decimals). I believe that's what drove int.__truediv__'s heroism: a desire to support that high-level promise about Python's numerics. BTW, the promise that numeric values that compare equal have the same hash code, regardless of type, is a tricky thing to support. Mark Dickinson nailed it :-)