On 3/19/2010 11:43 AM, Terry Reedy wrote: > On 3/19/2010 2:11 PM, Antoine Pitrou wrote: >> Raymond Hettinger<raymond.hettinger<at> gmail.com> writes: >>> >>> The reason to prefer an exception is that decimal/float comparisons >>> are more likely to be a programmer error than an intended behavior. > > If you really believe that, then equality comparisons should also be > disabled by raising NotImplemented or whatever. Totally agree. While the example most used in this thread is a less than operator, the text of the thread has never (as far as I have read) distinguished between equality, inequality, or relative signed magnitude comparisons. Sort has also been mentioned explicitly as an example. I perceive that the whole thread is about _all_ comparison operators with one float and one decimal operand currently producing an exception (3.x) or a type-based ordering (2.x). The type-based ordering has been demonstrated to produce unstable sorts in the presence of other types also, so is more of a problem than first perceived, and should be changed. > Clearly, someone who writes 'if somefloat == somedecimal:'assumes (now > wrongly) that the test might be true. This is just as buggy as an > order comparison. Raising an exception would consistently isolate > decimals from other numbers and eliminate the equality intransitivity > mess and its nasty effect on sets. Totally agree. > It still strikes me as a bit crazy for Python to say that 0.0 == 0 and > 0 == Decimal(0) but that 0.0 != Decimal(0). Who would expect such a > thing? The same person that would expect both 0 == "0" 0.0 == "0.0" to be False... i.e. anyone that hasn't coded in Perl for too many years. Glenn
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4