[Ben Rudiak-Gould <benrud...@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 ;-)
_______________________________________________
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/DZG2PFI6RFEFKYKVNXBM3IYGVXFRK5LQ/
Code of Conduct: http://python.org/psf/codeofconduct/
