[Guido] > But beware, IIRC there are pathological cases involving floats, (long) ints > and rounding where transitivity may be violated in Python (though I believe > only Tim Peters can produce an example :-).
Not anymore ;-) That is, while comparisons mixing bigints and floats may have suffered rounding surprises long ago, all cases of float-or-int compared-to float-or-int now act as if infinite precision were used. You can throw fractions.Fraction and (I believe) decimal.Decimal into that too. Except for NaNs in the floating types, there's a well-behaved total ordering now (whether doing mixed-type or intra-type comparisons). That doesn't make it surprise-free, though. For example, just last week someone on bugs.python.org flipped out ;-) upon learning >>> 10**100 == 1e100 False >>> 10**100 < 1e100 True Because, indeed, they don't denote the same "mathematical" value: >>> int(1e100) 10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104 >>> hex(_) '0x1249ad2594c37d0000000000000000000000000000000000000000000000000000000000000000000000' >>> (1e100).hex() '0x1.249ad2594c37dp+332' _______________________________________________ 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/6U6GTTQ4U3CPUS4QIAWGF22ZX2WOKUBD/ Code of Conduct: http://python.org/psf/codeofconduct/
