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
--
http://mail.python.org/mailman/listinfo/python-list
