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
_______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor