On 2/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Have you considered the third alternative that's been > mentioned -- a wrapper?
I don't like that at all. It's quite tricky to implement a fully transparent wrapper that supports all the special methods (__setitem__ etc.). It will be slower. And it will be more cumbersome to use. > The issue of __contains__ etc. could be sidestepped by > not giving the wrapper a __contains__ method at all. > If you want to do an 'in' test you do it on the > underlying dict, and then the semantics are clear. The semantics of defaultdict are crystal clear. __contains__(), keys() and friends represent the *actual*, *current* keys. Only __getitem__() calls on_missing() when the key is not present; being a "hook", on_missing() can do whatever it wants. What's the practical use case for not wanting __contains__() to function? All I hear is fear of theoretical bugs. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
