Feature Request: `operator.not_in`
Terry Jan Reedy
tjreedy at udel.edu
Fri Apr 19 14:27:49 EDT 2013
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
More information about the Python-list
mailing list