En Fri, 20 Apr 2007 23:48:02 -0300, Alex Martelli <[EMAIL PROTECTED]> escribió:
> Gabriel Genellina <[EMAIL PROTECTED]> wrote: > >> Reference Manual, 5.9 Comparisons >> >> "The objects need not have the same type. If both are numbers, they are >> converted to a common type. Otherwise, objects of different types always >> compare unequal, and are ordered consistently but arbitrarily." >> >> (Apart from the latter not menctioning string types too, looks good to >> me). > > Right. However, it might be worth underscoring that this applies to > _built-in_ types, and user-defined types are free to implement different > comparison semantics, although that should be done with care and good > taste; for example, one might have a collection type defining __eq__ to > mean "the same set of items as the other [iterable] operand in any > order", though that might cause weird behavior such as a==b but b!=a > (unfortunately there's no __req__, and __coerce__ is not involved in > comparisons either). BTW, I think that the relationship between __eq__ and __hash__ (a==b => hash(a)==hash(b), when hashable) should be more clearly stated too. I almost got insane some time ago because of a faulty Rational numbers implementation where hash(1/2)!=hash(2/4) (so dictionaries didn't work at all). -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list