[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