2010/8/1 Matthew Brett <matthew.br...@gmail.com>: >> Maybe it would be better to raise a ValueError, which is not caught by >> the evaluation mechanism, to prevent such stuff. > > Sorry that this is not yet clear to me, but, is it true then that: > > The only situation where array.__eq__ sensibly falls back to python > __eq__ is for the individual elements of object arrays?
Btw, I changed my opinion on that. The rationale was to inform the user about that numpy cannot do that. This is based on that Python cannot do better. But right this assumtion isn't true, since maybe the other operand knows quite well how to compare the pears to the apples, for whatever reason. So better stick to the documentation: "A rich comparison method may return the singleton NotImplemented if it does not implement the operation for a given pair of arguments." And since at the moment, the functionality is in fact "NotImplemented", this is the way to go at the moment. Of course, there is room for change, e.g., by breaking it down to the scalar level, if the r.h.s. is not a numpy.ndarray, and returning an array of Falses else. But even this is error-prone, because, the r.h.s. may be a descendant-class instance of numpy.ndarray, knowing better what to do, but being no longer asked. So I come to the conclusion, that in fact all "implementations" of the __eq__ for not-comparable dtypes aren't. They are just based on too many assumptions. They would be a replacement for a real implementation, for a real functionality. To come to your question, Matthew, I think I would tend to give the general recommendation to not mix dtypes which not really compare to each other. It's just error-prone. In fact, when you want to compare by Python's implementation of __eq__, which should in fact be the builtin cmp(), then object arrays are the way to go. But then you cannot use a single non-object ndarray. To summarise, numpy simply does not take part in __eq__ calculations where it does not know what to do. Python does the rest to ask the others about what they think about the operation. But the others should be ndarray-aware. Friedrich _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion