[Python-Dev] Proposal: defaultdict (original) (raw)

Ian Bicking ianb at colorstudy.com
Sun Feb 19 21:15:38 CET 2006

Michael Urman wrote:

On 2/19/06, Josiah Carlson <jcarlson at uci.edu> wrote:

My post probably hasn't convinced you, but much of the confusion, I believe, is based on Martin's original belief that 'k in dd' should always return true if there is a default. One can argue that way, but then you end up on the circular train of thought that gets you to "you can't do anything useful if that is the case, .popitem() doesn't work, len() is undefined, ...". Keep it simple, keep it sane. A default factory implementation fundamentally modifies the behavior of the mapping. There is no single answer to the question "what is the right behavior for contains, len, popitem" as that depends on what the code that consumes the mapping is written like, what it is attempting to do, and what you are attempting to override it to do. Or, simply, on why you are providing a default value. Resisting the temptation to guess the why and just leaving the methods as is seems the best choice; overriding contains to return true is much easier than reversing that behavior would be.

I agree that there is simply no universally correct answer for the various uses of default_factory. I think ambiguity on points like this is a sign that something is overly general.

In many of the concrete cases it is fairly clear how these methods should work. In the most obvious case (default_factory=list) what seems to be to be the correct implementation is one that no one is proposing, that is, "x in d" means "d.get(x)". But that uses the fact that the return value of default_factory() is a false value, which we cannot assume in general. And it effects .keys() -- which I would propose overriding for multidict (so it only returns keys with non-empty lists for values), but I don't see how it could be made correct for default_factory.

I just don't see why we should cram all these potential features into dict by using a vague feature like default_factory. Why can't we just add a half-dozen new types of collections (to the module of the same name)? Each one will get its own page of documentation, a name, a proper repr, and well defined meaning for all of these methods that it shares with dict only insofar as it makes sense to share.

Note that even if we use defaultdict or autodict or something besides changing dict itself, we still won't get a good contains, a good repr, or any of the other features that specific collection implementations will give us.

Isn't there anyone else who sees the various dict-like objects being passed around as recipes, and thinks that maybe that's a sign they should go in the stdlib? The best of those recipes aren't all-encompassing, they just do one kind of container well.

-- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org

More information about the Python-Dev mailing list