Path: csiph.com!usenet.pasdenom.info!news.albasani.net!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Fri, 19 Apr 2013 10:27:09 -0400
From: Matthew Gilson <m.gilson1@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: python-list@python.org
Subject: Feature Request: `operator.not_in`
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.823.1366382044.3114.python-list@python.org>
Lines: 34
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:43900

I believe that I read somewhere that this is the place to start 
discussions on feature requests, etc.  Please let me know if this isn't 
the appropriate venue (and what the appropriate venue would be if you know).

This request has 2 related parts, but I think they can be considered 
seperately:

1) 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`.

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.  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.  I don't see any reason why 
containment should behave differently.  `x in y` shouldn't necessarily 
imply `not x not in y`.  I'm not sure if `object` could have a default 
`__not_contains__` method (or whatever name seems most appropriate) 
implemented equivalently to:

      def __not_contains__(self,other):
           return not self.__contains__(other)

If not, it could probably be provided by something like 
`functools.total_ordering`.  Anyway, it's food for thought and I'm 
interested to see if anyone else feels the same way that I do.

Thanks,
~Matt