> > We need to be very careful about defining "not knowing". I (stongly) > > believe when the objects/types are incomparable (say the rings ZZ and > > QQ), then == should return False and != should return True. > > Sorry, I don't understand your example: I think everyone agrees that > ZZ == QQ should be False, but many people think that ZZ(1) == QQ(1) > should be True (though I personally disagree), and my post only was > about Elements. >
One potential side effect of what you're proposing is that ZZ == QQ should raise an error. How can we tell they are not equal? They are isomorphic as sets. ZZ is a subring of QQ and we could potentially test an infinite number of points and not find something distinct from QQ. What distinguishes them are their types (IntegerRing vs RationalField). > > > Subsequently, when there is no coercion between the parents, they > > should not raise an error. > > Regarding ==, I believe it is a matter of convenience and consistency. > Raising an error makes it easier to catch bugs, while returning False > when there is no coercion allows things like [a for a in [1, "banana"] > if a == 1]. > It also makes it *significantly* harder to work with heterogeneous data and really doesn't do too much to catch bugs. You end up with more complicated code that has to often consider more cases. Suppose ZZ(1) == QQ(1) raises an error. Then you have to manually do coercions and make extra sure about your data types in a weakly typed language, which is really hard from my experience. > > Regarding !=, I am less convinced. Returning True would imply that the > objects are known to be different (as opposed to: not known to be > equal, in the case of ==), while the coercion may not be implemented > but otherwise make perfect sense. > If the coercion is not implemented, then I would say that is a bug that would need to be fixed. However, that is a good point about != being not known to be == vs truly distinct. Although I would argue that not known to be equal is an equivalent problem to knowing to be distinct, and so the desire for an unknown result is good. Although it should not be an error. > > And in any case, I don't see what else than raising an error we could do > in the case of <, <=, >, >=. > > Here I completely agree with raising an error as you need some sort of (canonical) (partial) order, to which there often is none. Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
