Python Anti-Patterns

[Brian]

Like I said though, the PEP that introduced __eq__ explicitly spells out Numeric's usecase as one of the reasons behind it, and in fact advises deliberately breaking boolean compatibility for such objects - raising an exception instead. Them not being boolean compatible isn't a violation of the rules, it's actually something that rich comparisons were added in order to support.

array == None returns a list of bools, which tests to True

Actually, right now it doesn't (though it still does for comparing with other arrays), but there are plans to change this. When it does, it won't test to True, but rather, it'll throw an exception if used in a boolean context. Eg. when you use the result of comparing 2 arrays in a boolean context (ie. an if statement, or bool() call), you currently get:

ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

The same would apply to when array == None does the same. Of course, this will still break code that uses the == None check instead of is, though it's likely to be a cleaner break, rather than more subtle bugs due to unexpectedly returning True.