On 9/6/07, Noam Raphael <[EMAIL PROTECTED]> wrote: > > (Sorry, it turns out that I posted this reply only to Nick and not to > the list, so I post it again.) > > On 9/4/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > Containment and iteration really do need to be kept consistent and > > having the value matter when checking for dictionary containment would > > be outright bizarre. Put the two together and it makes sense for > > dictionary iteration and containment tests to both be based on keys. > > > I absolutely agree that containment and iteration should be kept > consistent. > > I suggest (again, ignoring backwards compatibility completely), that > "in" would behave according to the iteration, that is, check if the > tuple (key, value) is in dict.items(). If you prefer code: > > class DreamDict(dict): > def __iter__(self): > return self.iteritems() > def __contains__(self, (key, value)): > try: > myvalue = self[key] > except KeyError: > return False > return value == myvalue > > Indeed, the suggested "in" operator is not very useful, so you'll > usually use has_key. But I actually think that "d.has_key(k)" is > clearer than "k in d" - There's no "syntactic" reason why "k in d" > should mean "k in d.keys()" and not "k in d.values()".*
None of what you're saying is new. It's all been said back when iteration and containment testing were added to the dict type. The choice was explicitly made for the useful containment test, and the conforming iteration behaviour. The iteration is not actually less useful, it's just different. The net result of 'more useful + just as useful' is 'more useful'. I don't believe the actual experience in the three major releases since it was added, have convinced anyone that it's a bad idea (in fact, I had slight misgivings back then, but none what so ever now.) The mapping types simply don't act as containers of (key, value) pairs. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
