[Ben Rudiak-Gould <benrudiak@gmail.com>]
... Python follows the IEEE rounding model for float/float and int/int. Following it for float/int and int/float would be pretty easy since the hard work has already been done to support int/int.
It doesn't end there. Mark was asking about analogous behavior for mixing Fraction and float, and after that's answered "yes", the same for Decimal.
Let's just do it,
Who is "us"? I await your comprehensive patch ;-)
and not worry about whether it's hypocritical to fix this without fixing the bigger problem.
I'm not concerned with hypocrisy. I'm concerned that we'd be giving up a simple-to-understand rule about how mixing floats with other types works ("convert the other type to float, and if it's not representable as a float raise an exception"), and adding piles of delicate new code to cater to a "use case" that DOESN"T EXIST. In 3 decades. nobody ever asked for this.Eveni in this thread, the OP was just idly curious - they have no actual use for it either.
Once you start using slippery-slope arguments, pretty soon you're using them for everything, and progress grinds to a halt...
Curiously, that itself is a slippery-slope argument ;-)