Path: csiph.com!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Terry Jan Reedy <tjreedy@udel.edu>
Subject: Re: Feature Request: `operator.not_in`
Date: Fri, 19 Apr 2013 14:27:49 -0400
References: <5171543D.708@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
In-Reply-To: <5171543D.708@gmail.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.837.1366396079.3114.python-list@python.org>
Lines: 42
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:43926

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