[Bob Ippolito] > I think the use case mentioned was something like Numeric, where it may > be useful for anArray == anotherArray to return an array of bool, not a > single True or False The code in question is in Py_RichCompareBool() which *always* just returns True or False. That routine is called by list.__contains__() and many other functions that expect a yes or no answer. The regular rich comparison function, Py_RichCompare() is the same as it always was and can still return arrays of bools, complex numbers, or anything at all. IOW, we're still looking for a use case that warrants removing the identity-implies-equality guarantee out of Py_RichCompareBool(). My argument focused on the invariant assumptions that would be broken if this was done. Second, I don't believe that a sane use case will be found for an object x that returns False for "bool(x==x)" and that returns False for "x in [x]". Stretching ones mind to find such an object seems like an exercise in masochism. Raymond
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4