dictionary initialization

Jeff Shannon jeff at ccvcorp.com
Fri Nov 26 18:20:55 EST 2004


Weiguang Shi wrote:

>Personally, I think
>
>    a[i]++
>
>in awk is much more elegant than
>
>    if i in a: a[i] += 1
>    else: a[i] = 1
>  
>

As others have pointed out, the type of an uninitialized a[i] is 
ambiguous, and that Python doesn't want to try to guess what type to use 
based only on the type of the RHS.  Depending on what, exactly, the RHS 
*is*, there may be multiple likely types for the LHS.  The case where 
the RHS is an integer is one of the clearer special cases, but Python's 
default behavior should be the same regardless of what type the RHS is, 
and it doesn't seem safe to assume that the LHS type should always be 
equivalent to the RHS type.

But there's another level of ambiguity here.  In many cases, throwing an 
error for an uninitialized dict item *is* the correct behavior.  Suppose 
I've got an ascii string representing a DNA gene sequence, and I want to 
calculate the relative prevalence of various bases.  It's pretty 
straightforward to go through and count up how many of each character 
there are, using a dict -- but if somehow a letter other than A, G, C, 
or T is present, I don't want it to pass silently.  It's something very 
strange/wrong, and I want to be notified immediately.

Now, in the counting that *you* happen to be doing, assuming that a 
default value is desirable works.  But that's not universal.  And it's 
easier to use one of various methods to create a default value (as Bengt 
Richter demonstrated) than it is to consistently check that the dict 
keys are limited to a particular set of desired keys.

Also, it's not that hard to subclass dict to provide the functionality 
that you want.  I expect that googling on the c.l.p archives would turn 
up more than one recipe for a dict with default values.  (There may even 
be such a thing in the Python Cookbook.)  I know I've seen such things 
posted here (though not recently).

Jeff Shannon
Technician/Programmer
Credit International





More information about the Python-list mailing list