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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
