This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Three __contains__ implementations
Type: Stage:
Components: Library (Lib) Versions: Python 2.3
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: Nosy List: brett.cannon, exarkun, rhettinger
Priority: normal Keywords:

Created on 2003-01-21 22:18 by exarkun, last changed 2022-04-10 16:06 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
bisect.py exarkun, 2003-01-21 22:20
contains.diff exarkun, 2003-01-22 02:16
Messages (6)
msg14157 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2003-01-21 22:18
  Several classes in the stdlib implement dict-like
interfaces, but do not provide __contains__
definitions.  This is mentioned in PEP290 as a
"contra-indication" for updating code to use "k in d".
 The attached patch adds __contains__ implementations
for these stdlib classes.  As far as I can tell, this
brings all the dict-like classes in the stdlib "up to
date", so perhaps PEP290 should be updated as well.
msg14158 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2003-01-22 00:44
Logged In: YES 
user_id=357491

The attached file has no ``__contains__`` definitions for anything.  Did you attach the correct file?
msg14159 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2003-01-22 02:16
Logged In: YES 
user_id=366566

Either mozilla or sf is screwing with me.  *grumble* 
There's no way I selected bisect.py for attachment.  Proper
file now attached.
msg14160 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2003-01-22 04:51
Logged In: YES 
user_id=357491

The code itself looks fine, but I would suggest that instead of copying code from the methods that provide the same that you change them so that the old method calls ``__contains__`` and that ``__contains__`` now takes over as the primary method.  So instead of::

     def has_key(self, name):
         return self._attrs.has_key(name)
 
    def __contains__(self, name):
        return self._attrs.has_key(name)

do::

   def has_key(self, name):
         return self.__contains__(name)

   def __contains__(self, name):
         return self._attrs.has_key(name)


Doing it this way minimizes code duplication along with the possibility of someone changing one method and not the other.

And as for usefulness of these additions, I can't comment since I use none of the modules patched, but I see no harm in adding the functionality.  So  +0 from me on applying the patch once the above changes are done.
msg14161 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2003-01-25 03:30
Logged In: YES 
user_id=80475

This patch is fine as it stands.  Brett's point is well taken, 
but using 'in' should never result in a reduced 
performance. IMO, the additional layer of indirection isn't 
worth it.

PEP 290 needs to stay "as is" because it still applies to 
home-grown and third-party modules.

msg14162 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2003-01-30 01:03
Logged In: YES 
user_id=80475

Applied as:

lib-tk/Canvas.py 1.18
plat-riscos/riscosenv 1.6
xml/sax/xmlreader.py 1.17
History
Date User Action Args
2022-04-10 16:06:10adminsetgithub: 37816
2003-01-21 22:18:43exarkuncreate