GUI Frames and classmethod

[Jeremy Bowers]

On Mon, 06 Dec 2004 14:11:04 -0800, Scott David Daniels wrote:
> Second, I was referring to code like:
> 
>       try:
>           inner = table[state]
>       except KeyError:
>           table[state] = inner = {}
>       inner[action] = whatever
> 
> vs. code like this:
> 
>       table[state, action] = whatever
> 
> That is, dynamic table modification code for a table of pairs is clearer.

But it isn't quite as tradeoff free as you say; you do lose the ability to
say table[state] and get just the information relevant to your state (you
might take the .keys() of that or something).

In this case, it may not be a big deal; depends on what the program does
and how the programmer thinks. In other cases, dicts of dicts can make
perfect sense. For instance, I have a Registry type that uses
dicts-in-dicts the obvious way to store things like
"table1.table2.table3.value", and that way there is a coherent way to pass
"table1.table2.table3" around. Yeah, you could work out a string or tuple
subclass that could still work, but that's a lot more work :-) and you'd
still have a hard time getting all keys from a table without searching the
whole thing.