Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #43926

Re: Feature Request: `operator.not_in`

Show key headers only | View raw

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

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread

Thread

Re: Feature Request: `operator.not_in` Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-19 14:27 -0400

csiph-web