Guido van Rossum wrote: > Maybe we should just call off the odd NaN comparison behavior? This doesn't solve the broader problem that *any* type might deliberately define non-reflexive equality, and therefore people will still be surprised by >>> x = SomeObject() >>> x == x False >>> [x] == [x] True The "problem" (if it is a problem) here is list, not NANs. Please don't break NANs to not-fix a problem with list. Since we can't (can we?) prohibit non-reflexivity, and even if we can, we shouldn't, reasonable solutions are: (1) live with the fact that lists and other built-in containers will short-cut equality with identity for speed, ignoring __eq__; (2) slow containers down by guaranteeing that they will use __eq__; (but how much will it actually hurt performance for real-world cases? and this will have the side-effect that non-reflexivity will propagate to containers) (3) allow types to register that they are non-reflexive, allowing containers to skip the identity shortcut when necessary. (but it is not clear to me that the extra complexity will be worth the cost) My vote is the status quo, (1). -- Steven
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