Mark Dickinson wrote:
> Unrelated question: under this proposal, what would you want
> `Fraction(10**400) / 1e200` to do?
Somehow that sounds like a trick question :-). I'd say 1e200, yes, although didn't think much about it.
Well, maybe a little.
One of the benefits of the current design is that we only need homogeneous per-type arithmetic operations: the implementation only needs to be able to multiply a float by another float, or an int by another int, or a complex number by another complex number. And then adding in the rules for upcasting gives us the benefit of mixed-type arithmetic with little expense in terms of additional complexity in the implementation.
But if we start adding inhomogeneous mixed-type arithmetic that's a whole lot more cases that have to be covered - we now potentially need one addition rule per pair of types, instead of just one addition rule per type. So we'd likely end up with dedicated complex * float, float * int, Fraction * float, Fraction * complex, ... operations. And we have to do this for a whole bunch of operations, not just division. For example, it would be oddly inconsistent to special-case 10**400 / 1e200 but not 1e-200 * 10**400.
And I suspect that the more complex rules would also make life much more difficult for 3rd-party numeric types that want to play nice with the builtin types.
There's definitely potential benefit in some of this - e.g., It Would Be Nice If `-1 * complex(inf, 0.0)` gave `complex(-inf, -0.0)` instead of the current result of `complex(-inf, nan)`. But the price in added complexity - both conceptual complexity and implementation complexity - seems too high.
Btw the full error message I get for that is "OverflowError: integer division result too large for a float". Even for `Fraction(10**400, 3) / 3.14`. Saying "integer division" when neither operand is an integer and I'm also not using `//` feels suboptimal.
Agreed; I'm sure there's room for improvement in the error messages.
--
Mark