[Python-Dev] Proposal: defaultdict

Guido van Rossum guido at python.org
Fri Feb 17 23:15:39 CET 2006

On 2/17/06, Ian Bicking <ianb at colorstudy.com> wrote:
> Guido van Rossum wrote:
> > d = {}
> > d.default_factory = set
> > ...
> > d[key].add(value)
> Another option would be:
>    d = {}
>    d.default_factory = set
>    d.get_default(key).add(value)
> Unlike .setdefault, this would use a factory associated with the
> dictionary, and no default value would get passed in.  Unlike the
> proposal, this would not override __getitem__ (not overriding
> __getitem__ is really the only difference with the proposal).  It would
> be clear reading the code that you were not implicitly asserting they
> "key in d" was true.
> "get_default" isn't the best name, but another name isn't jumping out at
> me at the moment.  Of course, it is not a Pythonic argument to say that
> an existing method should be overridden, or functionality made nameless
> simply because we can't think of a name (looking to anonymous functions
> of course ;)

I'm torn. While trying to implement this I came across some ugliness
in PyDict_GetItem() -- it would make sense if this also called
on_missing(), but it must return a value without incrementing its
refcount, and isn't supposed to raise exceptions -- so what to do if
on_missing() returns a value that's not inserted in the dict?

If the __getattr__()-like operation that supplies and inserts a
dynamic default was a separate method, we wouldn't have this problem.

OTOH most reviewers here seem to appreciate on_missing() as a way to
do various other ways of alterning a dict's __getitem__() behavior
behind a caller's back -- perhaps it could even be (ab)used to
implement case-insensitive lookup.

I'm not going to do a point-by-point to your longer post (I don't have
the time); let's (again) agree to disagree and I'll sleep on it.

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list