Antoon Pardon wrote: > Op 2006-01-10, Peter Decker schreef <[EMAIL PROTECTED]>:
>>I don't see the two comparisons as equivalent at all. If two things >>are different, it does not follow that they can be ranked. > > > That a < b returns false doesn't imply that a and b can be ranked. > take sets. set([1,2]) and set([1,3)) can't be ranked but > set([1,2]) < set([1,3)) returns False just as set([1,2]) > set([1,3)) > does. Breaking my resolution already, but you're ignoring the fact that the set type uses the '<' and '>' operators from a set-theoretic, not number-theoretic point of view. Saying "set(1,3) is greater than set(1,2)" is meaningless (and not false), because the mathematical basis of the operator in this context is superset -- "set(1,3) is a superset of set(1,2)" is well-defined and false. Set uses '<' and '>' because the superset and subset symbols aren't on the keyboard. In languages that allow operator overloading, there are always some well-defined cases where the operator is the simplest, clearest notation yet the operator has a meaning very distinct from the arithmetical operation. As another example, Pyparsing uses '<<' to "load" a Forward declaration, for recursive grammars -- this obviously has nothing to do with bit-shifting. Of course, cases like these two are fairly textbook examples for the argument that operator overloading is unclear; Python accepts the occasional ambiguity and allows (indeed encourages, to a reasonable degree) operator overloading for conciseness and expressiveness. To reply to your other argument, Antoon: > Maybe python should adopt both approaches and introduce a new family > of comparators. Then one family will always succeed and the other > family can throw an exception. [snip] > I think it is usefull because when I am looking for 1 in a list, > I'm not necessarily happy when I find 1.0 or decimal("1"). I personally feel that the use cases for this "other" comparison (===?) are very restricted. In fact, your example itself isn't even a use-case for this operator, because integer/float/decimal have well-defined equality comparisons already (that explicitly account for different types) -- the implicit "not is implies !=, if __eq__ isn't defined" behaviour isn't triggered. The use-case for a "===" operator would seem to be restricted to when program behaviour is determined soley by "a" not equalling "b." If a "wrong" object is referenced by "b," then the program might do a Bad Thing, because it expects "b" to be something else... except that the error would be caught later anyway -- probably by calling "b.method()" or somesuch. In fact, even in more esoteric cases the behaviour of "==" as-is is useful; in the itertools.izip_longest discussion, this behaviour is implicitly used in the sentinel-stopping method (izip(chain(iter,sent),chain(iter,sent),...,stop=(sent,sent,sent,...)), to badly mangle the syntax). -- http://mail.python.org/mailman/listinfo/python-list