On 4/19/2013 10:27 AM, Matthew Gilson wrote:
) It seems to me that the operator module should have a `not_in` or
`not_contains` function. It seems asymmetric that there exists a
`is_not` function which implements `x is not y` but there isn't a
function to represent `x not in y`.
There is also no operator.in.
There is operator.contains and operator.__contains__.
There is no operator.not_contains because there is no __not_contains__
special method. (Your point two, which I disagree with.)
2) I suspect this one might be a little more controversial, but it seems
to me that there should be a separate magic method bound to the `not in`
operator.
The reference manual disagrees.
"The operator not in is defined to have the inverse true value of in."
Currently, when inspecting the bytecode, it appears to me
that `not x in y` is translated to `x not in y` (this supports item 1
slightly). However, I don't believe this should be the case. In
python, `x < y` does not imply `not x >= y` because a custom object can
do whatever it wants with `__ge__` and `__lt__` -- They don't have to
fit the normal mathematical definitions.
The reason for this is that the rich comparisons do not have to return
boolean values, and do not for numarray arrays which, I believe,
implement the operators itemwise.
> I don't see any reason why containment should behave differently.
'Design by analogy' is tricky because analogies often leave out
important details. __contains__ *is* expected to return true/false.
" object.__contains__(self, item)
Called to implement membership test operators. Should return true
if item is in self, false otherwise"
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
