[IronPython] Potential issue with the 'in' construction?

Sylvain Hellegouarch sh at defuze.org
Thu Jan 18 16:56:23 CET 2007


Hi folks,

Say I have the following class:

class Test(dict):
    def __getitem__(self, key):
        print "__gelitem__ called"
        return dict.__getitem__(self, key.title())

    def __setitem__(self, key, value):
        print "__selitem__ called"
        dict.__setitem__(self, key.title(), value)

    def __delitem__(self, key):
        print "__delitem__ called"
        dict.__delitem__(self, key.title())

    def __contains__(self, key):
        print "__contains__ called"
        return dict.__contains__(self, key.title())

    def has_key(self, key):
        print "has_key called"
        return dict.__contains__(self, key.title())

Now say I have this code:

if __name__ == "__main__":
    u = Test()
    u['simple'] = 'text'
    print u.keys()
    print 'simple' in u
    print u.__contains__('simple')
    print u.has_key('simple')
    print u['simple']
    del u['simple']

I will get the following output:

__selitem__ called
['Simple']
False
__contains__ called
True
has_key called
True
__gelitem__ called
text
__delitem__ called


As you can see all the overridden methods were correctly called except
the __contains__ on 'in' construction.

The same test with CPython:

__selitem__ called
['Simple']
__contains__ called
True
__contains__ called
True
has_key called
True
__gelitem__ called
text
__delitem__ called


In that case everything is as I expected.

So could there be a problem on the way IP manages "in"?

This looks like a minor bug but prevent me from running CherryPy 3 which
uses the same type of Case Insensitive dict to handle easily HTTP headers.

Thoughts on a workaround or fix?
- Sylvain



More information about the Ironpython-users mailing list