On Sun, Feb 20, 2022 at 9:41 AM Tim Peters <tim.pet...@gmail.com> wrote:
> It's a slippery slope, of scant discernible benefit, and still hackish. > For example, 10**600 / 1e200 / 1e200. > That's how IEEE arithmetic works: a/b is computed to infinite precision then properly rounded, but (a/b)/c isn't. Yes, it's not ideal, but it was doable, and was better than not even having consistent behavior for a/b, which was the state of things before the standard. 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. Let's just do it, and not worry about whether it's hypocritical to fix this without fixing the bigger problem. Once you start using slippery-slope arguments, pretty soon you're using them for everything, and progress grinds to a halt...
_______________________________________________ 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/UJQWFDWOOGYQDWWDT5CVLF4HN3ML7NBU/ Code of Conduct: http://python.org/psf/codeofconduct/
