[Python-Dev] Proposal: defaultdict

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