[Python-Dev] defaultdict proposal round three (original) (raw)

Brett Cannon brett at python.org
Tue Feb 21 00:04:57 CET 2006

On 2/20/06, Steven Bethard <steven.bethard at gmail.com> wrote:

I wrote: > # I want to do dd[item] += 1

Guido van Rossum wrote: > You don't need a new feature for that use case; d[k] = d.get(k, 0) + 1 > is perfectly fine there and hard to improve upon. Alex Martelli wrote: > I see d[k]+=1 as a substantial improvement -- conceptually more > direct, "I've now seen one more k than I had seen before". Guido van Rossum wrote: > Yes, I now agree. This means that I'm withdrawing proposal A (new > method) and championing only B (a subclass that implements > getitem() calling onmissing() and onmissing() defined in that > subclass as before, calling defaultfactory unless it's None). Probably already obvious from my previous post, but FWIW, +1. Two unaddressed issues: * What module should hold the type? I hope the collections module isn't too controversial. * Should defaultfactory be an argument to the constructor? The three answers I see: - "No." I'm not a big fan of this answer. Since the whole point of creating a defaultdict type is to provide a default, requiring two statements (the constructor call and the defaultfactory assignment) to initialize such a dictionary seems a little inconvenient. - "Yes and it should be followed by all the normal dict constructor arguments." This is okay, but a few errors, like defaultdict({1:2}) will pass silently (until you try to use the dict, of course). - "Yes and it should be the only constructor argument." This is my favorite mainly because I think it's simple, and I couldn't think of good examples where I really wanted to do ``defaultdict(list, somedictoriterable)ordefaultdict(list, **somekeywordargs)``. It's also forward compatible if we need to add some of the dict constructor args in later.

While #3 is my preferred solution as well, it does pose a Liskov violation if this is a direct dict subclass instead of storing a dict internally (can't remember the name of the design pattern that does this). But I think it is good to have the constructor be different since it does also help drive home the point that this is not a standard dict.

-Brett

More information about the Python-Dev mailing list