Mike Meyer wrote: >> 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.
Seconded. All hell would break loose if Python didn't allow == for heterogenous types, $DEITY only knows how many types I relied on it. Please don't let it go in Py3k. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
