On Sun, Feb 20, 2022 at 3:59 PM Stefan Pochmann <smpochm...@gmail.com> wrote:
> 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
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OXEFZMWZV47BFBQJVVVCUPPEP5QIVRUX/ Code of Conduct: http://python.org/psf/codeofconduct/
