Rich Comparisons Gotcha

[Terry Reedy]

Rasmus Fogh wrote:

> For my personal problem I could indeed wrap all objects in a wrapper with
> whatever 'correct' behaviour I want (thanks, TJR). It does seem a bit

I was not suggesting that you wrap *everything*, merely an adaptor for 
numpy arrays in whatever subclass and source it is that feeds them to 
your code.  It is fairly unusual, I think, to find numpy arrays 'in the 
wild', outside the constrained context of numerical code where the 
programmer uses them intentionally and hopefully understands their 
peculiarities.

> much, though, just to get code like this to work as intended:
>   alist.append(x)
>   print ('x is present: ', x in alist)

Even if rich comparisons as you propose, the above would *still* not 
necessarily work.  Collection classes can define a __contains__ that 
overrides the default and that can do anything, though True/False is 
recommended.

As best I can think of at the moment, the only things you can absolutely 
depend on is that builtin id(ob) will return an int, that 'ob1 is ob2' 
(based in id()) will be True or False, and that builtin type(ob) will be 
a class (at least in 3.0, not sure of 2.x).  The names can be rebound 
but you can control that within the module you write.

This is what I meant when I said that 'generic' nearly always needs to 
be qualified to something like 'generic for objects that meet the 
interface requirements'.  Every function has that precondition as part 
of its implied contract.  Your code has an interface requirement that 'x 
in y' not raise an exception.  An x,y pair that does it outside its 
contract.

Terry Jan Reedy