[Tutor] a ScoreList class (was: Multiple identical keys in a
dictionary)
Bruce Sass
bsass@freenet.edmonton.ab.ca
Mon, 28 May 2001 04:29:28 -0600 (MDT)
On Mon, 28 May 2001, wheelege wrote:
<...>
> Heh - I should explain in more detail. I already have a detailed class to
:)
<...>
> What I ended up deciding on was a dictionary where the keys were scores
> and the values are a list of lists (which have name, level, difficulty in
> them). The time spent displaying or grabbing values is actually quite fast,
> since I'm using a dictionary, and because I can have more than one entry for
> each score, it is easy to handle multiple similar scores.
Ya, I was thinking along those lines (list, dict, class, whatever)
with ScoreList.__add__
<...>
> > self.level = level
> > # there may be other things to keep track of, like...
<...>
> :) The way I wrote my class it is in fact very easy to add further
> attributes...all you do is pass an additional argument to it's 'update'
> method and everything will work fine...although I do agree having an object
> to hold each value would be much 'cleaner' and although no more
> possibilities (what can a class have as an attribute that a list can't have
> as an item?) it is nicer to think about.
There are almost too many ways to add properties to an instances
(seems to be a regular theme on c.l.p. :)
> > def __cmp__(self, other):
> > """Allows for comparison with other Score-s and numerics."""
<...>
> Now that's something I didn't think about...although I didn't have to
> because I ended up using a dictionary :)
> Very cool.
At one point I figured it would be nice to have a sort() come out in
descending order, like you expect from a displayed list of scores.
Of course, "if score1 < score2:", came out backwards. :) [cont...]
<...>
> > def __add__(self, score):
> > # I think this bit is most significant; it defines the
> > #... semantics of adding to the list and is where you would
> > #... do any 'magic' needed to ensure the list has the
> > #... properties you want. So far the only 'magic' is the
> > #... disappearing score if it is below the cutoff.
> > if self.cutoff == None or score > self.cutoff:
> > self.values.append(score)
> > return ScoreList(self.values, self.cutoff)
>
> Right now this is implemented by the size of the actual high scores file -
> top limit 1k, lowest scores being cut off when the limit is reached. The
> user can ask for how many they wish to see inside the 'Hall of Fame' dialog
> (generated by the HighScores.display() method, coincidentally) so a cutoff
> as such isn't such an important thing.
> Unless storing a (potentially) 1k long dictionary is a problem for a
> computer...
Ya, I was thinking big (all the scores in the list, except for the
wimps who didn't even try), and considering that a limit on the number
of entries may be needed (or maybe users named bob21 couldn't post
scores when the moon was full, whatever [played nethack?]).
<...>
[...cont]
> > def top(self, number):
> > self.values.sort()
> > return ScoreList(self.values[-number:], self.cutoff)
While thinking about getting "print aScoreList" to spit out in
descending order, I discovered that this...
def top(self, number):
self.values.sort()
self.values.reverse()
return ScoreList(self.values[:number], self.cutoff)
...doesn't do the same as reversing the sense of Score.__cmp__ :/
In fact, reverse() doesn't appear to do anything.
Since it was almost as late then as it is now, I didn't investigate
any further... maybe tomorrow....
Any ideas?
<...>
> Perhaps if something mind-boggling evil comes of the ye olde 'dictionary'
> approach and a rewrite is neccessary I will go for the class implementation.
> In which case I will be happy for this discussion :)
I was thinking a dict may be better than a list (for the Score
objects) if a ScoreList had a lot of Scores... not sure what the best
key would be, probably depend on the game and players (is it just a
list of scores, or will players want to analyse it for weaknesses in
their opponents, kinda thing).
- Bruce