[Tutor] More or less final Chutes & Ladders

[Keith Winston]

Thanks Alan & Denis: Alan, the improvement you suggested had already been
made, and adopted. Good catch.

Denis: alas, there are chutes and ladders dicts, but I guess your chutes &
ladders lists are local to the results class... Your suggestion is quite
shocking to me, I wouldn't have thought of creating a class for results...
I guess it allows clearer modularity of the final candl_array? I don't
really get it... I think you are using it, essentially, for nothing other
than a data structure, right? And some cleaner print options, though I have
only looked at the raw game data for debugging... it's a great suggestion,
obviously, because I am a little dumbfounded by it, and it's making me
think.

My initial reaction is concern about having too many classes, but I don't
really have any sense of how important that is. I was playing with storing
ChutesAndLadders instances in my game array, but of course they include all
their methods, etc: all kinds of overhead (at least, that's my impression),
which is why I created the results method, so I could just pass a... list?
composite object? Collection? I can't really sort out what the latter two
mean in Python, and must be looking in the wrong place... while I was
researching I found out about namedtuple(), which seems like a promising
structure for game data, but I haven't really looked into it. It might also
be a collection...

The entire game is to be played in bulk (that is, it's really a statistical
foray, albeit a silly one), so the candl_array might get large (perhaps
millions of "records" -- results lists). Is there some way the Results
class helps that?

keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20140104/281bbab2/attachment-0001.html>