Robert Kern wrote:
Terry Reedy wrote:
Rasmus Fogh wrote:
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.
No, it's actually required.
In [4]: class A(object):
def __contains__(self, other):
return 'foo'
...:
...:
In [7]: a = A()
In [8]: 1 in a
Out[8]: True
Okay, so it will coerce to True/False for you, but unlike rich
comparisons, the return value must be interpretable as a boolean.
Interesting. I did not expect that from "Should return true if item is
in self, false otherwise.", but maybe the lowercase true/false is an
(undocumented?) abbreviation for 'object with Boolean value True/False'.
Of course, if the return value is not so interpretable, or if
__contains__ raises an exception, there is no coercion and the OP's code
will not work.
A different summary of my main point in this thread: Dynamic binding and
special method hooks make somewhat generic code possible, but the same
special method hooks make absolutely generic code nearly impossible.
tjr
--
http://mail.python.org/mailman/listinfo/python-list
