On 22/12/2020 19:08, Brett Cannon wrote:

... The fact that numpy chooses to implement __eq__ in such a way that its result would be surprising if used in an `if` guard I think is more a design choice/issue of numpy than a suggestion that you can't trust `==` in testing because it _can_ be something other than True/False.

+1  In addition to NumPy's regularly surprising interpretation of operators, it is evident from Ivan Pozdeev's investigation (other branch) that part of the problem lies with bool(np.array) being an error. I can see why that might be sensible. You can have one or the other, but not both.

I wondered if Python had become stricter here after NumPy made its choices, but a little mining turns up:

"New in version 2.1. These are the so-called ``rich comparison'' methods, and are called for comparison operators in preference to __cmp__() below. The correspondence between operator symbols and method names is as follows: x<y calls x.__lt__(y), x<=y calls x.__le__(y), x==y calls x.__eq__(y), x!=y and x<>y call x.__ne__(y), x>y calls x.__gt__(y), and x>=y calls x.__ge__(y). These methods can return any value, but if the comparison operator is used in a Boolean context, the return value should be interpretable as a Boolean value, else a TypeError will be raised. By convention, 0 is used for false and 1 for true. "

https://docs.python.org/release/2.1/ref/customization.html

The combination of choices makes the result of a comparison, about which there is some freedom, not interpretable as a boolean value. We are warned that this should not be expected to work. Later docs (from v2.6) refer explicitly to calling bool() as a definition of "interpretable". bool() is there from v2.3.

Jeff Allen