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


Groups > comp.lang.python > #43926 > unrolled thread

Re: Feature Request: `operator.not_in`

Started byTerry Jan Reedy <tjreedy@udel.edu>
First post2013-04-19 14:27 -0400
Last post2013-04-19 14:27 -0400
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

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

#43926 — Re: Feature Request: `operator.not_in`

FromTerry Jan Reedy <tjreedy@udel.edu>
Date2013-04-19 14:27 -0400
SubjectRe: Feature Request: `operator.not_in`
Message-ID<mailman.837.1366396079.3114.python-list@python.org>
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

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web