[Python-Dev] Proposal: defaultdict

Adam Olsen rhamph at gmail.com
Mon Feb 20 19:22:30 CET 2006

On 2/20/06, Aahz <aahz at pythoncraft.com> wrote:
> On Sun, Feb 19, 2006, Josiah Carlson wrote:
> >
> > I agree, there is nothing perfect.  But at least in all of my use-cases,
> > and the majority of the ones I've seen 'in the wild', my previous post
> > provided an implementation that worked precisely like desired, and
> > precisely like a regular dictionary, except when accessing a
> > non-existant key via: value = dd[key] . __contains__, etc., all work
> > exactly like they do with a non-defaulting dictionary. Iteration via
> > popitem(), pop(key), items(), iteritems(), __iter__, etc., all work the
> > way you would expect them.
> This is the telling point, IMO.  My company makes heavy use of a "default
> dict" (actually, it's a "default class" because using constants as the
> lookup keys is mostly what we do and the convenience of foo.bar is
> compelling over foo['bar']).  Anyway, our semantics are as Josiah
> outlines, and I can't see much use case for the alternatives.

Can you say, for the record (since nobody else seems to care), if
d.getorset(key, func) would work in your use cases?

> Those of you arguing something different: do you have a real use case
> (that you've implemented in real code)?

(again, for the record) getorset provides the minimum needed
functionality in a clean and intuitive way.  Why go for a complicated
solution when you simply don't need it?

Adam Olsen, aka Rhamphoryncus

More information about the Python-Dev mailing list