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, ac
Zak Arntson wrote:
On Mon, 06 Dec 2004 13:08:15 -0800, Scott David Daniels
<[EMAIL PROTECTED]> wrote:
Zak Arntson wrote:
On Fri, 03 Dec 2004 14:48:30 -0800, Scott David Daniels wrote:
...The real advantage is clarity: the inner dictionaries in a dict-of-dict
implementation have no real "meaning."
On Mon, 06 Dec 2004 13:08:15 -0800, Scott David Daniels
<[EMAIL PROTECTED]> wrote:
> Zak Arntson wrote:
> > On Fri, 03 Dec 2004 14:48:30 -0800, Scott David Daniels
> Most likely so. Possibly an equal amount of has work -- hash of a pair
> is a function of hashes of the lelements, but fewer trips i
Zak Arntson wrote:
On Fri, 03 Dec 2004 14:48:30 -0800, Scott David Daniels
<> wrote:
question: A dictionary of dictionaries is slower than a
dictionary of tuples, right? Because when Python accesses a
dictionary, it produces a hash from the key and finds that in its hash
table. Producing a has
On Fri, 03 Dec 2004 14:48:30 -0800, Scott David Daniels
<[EMAIL PROTECTED]> wrote:
> Zak Arntson wrote:
> > My current approach is that in the Frame class, I have a method to
> > call _after_ initialization that creates a bunch of dummy methods so
> > the user doesn't have to implement EVERY sta
Zak Arntson wrote:
Note the last line. When programming EVERY child I have to remember to
add this self.create_empty_state_methods() line.
My question: What are Pythonic alternatives to this sort of thing?
Now I can't be the first person to want a pre- and post- child init code!
> I'm worried that
I'm currently implementing a game GUI, where there are three
components to the screen: A battle, a command button area and a city
view area. Each of these are rectangular, and handle interactions in
different ways.
For example, on the battle "frame" you can select units, right-click
to deliver con
