default behavior

[Steven D'Aprano]

On Fri, 30 Jul 2010 07:59:52 -0400, wheres pythonmonks wrote:

> Instead of defaultdict for hash of lists, I have seen something like:
> 
> 
> m={}; m.setdefault('key', []).append(1)
> 
> Would this be preferred in some circumstances? 

Sure, why not? Whichever you prefer.

setdefault() is a venerable old technique, dating back to Python 2.0, and 
not a newcomer like defaultdict.


> Also, is there a way to upcast a defaultdict into a dict?

"Upcast"? Surely it is downcasting. Or side-casting. Or type-casting. 
Whatever. *wink*

Whatever it is, the answer is Yes:

>>> from collections import defaultdict as dd
>>> x = dd(int)
>>> x[1] = 'a'
>>> x
defaultdict(<type 'int'>, {1: 'a'})
>>> dict(x)
{1: 'a'}



> I have also heard some people use
> exceptions on dictionaries to catch key existence, so passing in a
> defaultdict (I guess) could be hazardous to health.  Is this true?

Yes, it is true that some people use exceptions on dicts to catch key 
existence. The most common reason to do so is to catch the non-existence 
of a key so you can add it:

try:
    mydict[x] = mydict[x] + 1
except KeyError:
    mydict[x] = 1


If mydict is a defaultdict with the appropriate factory, then the change 
is perfectly safe because mydict[x] will not raise an exception when x is 
missing, but merely return 0, so it will continue to work as expected and 
all is good.

Of course, if you pass it an defaultdict with an *inappropriate* factory, 
you'll get an error. So don't do that :) Seriously, you can't expect to 
just randomly replace a variable with some arbitrarily different variable 
and expect it to work. You need to know what the code is expecting, and 
not break those expectations too badly.

And now you have at least three ways of setting missing values in a dict. 
And those wacky Perl people say that Python's motto is "only one way to 
do it" :)



-- 
Steven