Home Original page

[Python-Dev] defaultdict proposal round three

Guido van Rossum guido at python.org
Tue Feb 21 03:12:50 CET 2006 
On 2/20/06, Greg Ewing <greg.ewing at canterbury.ac.nz> 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/)
More information about the Python-Dev mailing list