[EMAIL PROTECTED] writes:
> My question is, what reasons are left for leaving the current default
> equality operator for Py3K, not counting backwards-compatibility?
> (assume that you have idset and iddict, so explicitness' cost is only
> two characters, in Guido's example)
Yes. Searching for items in heterogenous containers. With your change
in place, the "in" operator becomes pretty much worthless on
containers of heterogenous objects. Ditto for container methods that
do searches for "equal" members. Whenever you compare two objects that
don't have the same type, you'll get an exception and terminate the
search. If the object your searching for would have been found
"later", you lose - you'll get the wrong answer.
You could fix this by patching all the appropriate methods. But then
how do you describe their behavior, without making some people expect
that it will raise an exception if they pass it incomparable types?
Also, every container type now has this split between identity and
equality has to be dealt with for *every* container class. If you want
identity comparisons on objects, you have to store them in an idlist
for the in operator and index methods to work properly.
I also think your basic idea is wrong. The expression "x == y" is
intuitively False if x and y aren't comparable. I'd say breaking that
is a bad thing. But if you don't break that, then having "x == y"
raise an exception for user classes seems wrong. The comparison should
be False unless they are the same object - which is exactly what
equality based on id gives us.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
