On Mon, Nov 11, 2013 at 3:32 AM, Chris Angelico <ros...@gmail.com> wrote: > On Mon, Nov 11, 2013 at 10:17 PM, Steven D'Aprano > <steve+comp.lang.pyt...@pearwood.info> wrote: >> On Mon, 11 Nov 2013 21:39:27 +1100, Chris Angelico wrote: >>> denormalizes it into a lookup table by creating 70 entries quoting the >>> first string, 15 quoting the second, 5, and 10, respectively. >> >> Ewww :-( >> >> Imagine having to print out the dict looking for an error in the lookup >> table. Or imagine the case where you have: >> >> 0...20000: do this >> 20001...890001: do that >> 890001...890003: do something else >> >> Don't get me wrong, it's a clever and reasonable solution for your >> specific use-case. But I'd much rather have a lookup table variant that >> matches on intervals. > > Of course it's "Ewww" in isolation :) But just imagine there are piles > and piles of these tables, themselves keyed by keyword, and I want to > be able to let untrusted people create tables (which means they > basically have to be data, not code). Also, bear in mind, all the > tables are based around dice that can be physically rolled, so none > has more than 100 entries after denormalization. Quite a lot of the > tables actually have unique entries per value (eg it's a d10 roll, > with ten unique outputs), so it's simplest to just turn all the tables > into that format; that way, the main code needs worry about one type > only, and the preprocessor handles the denormalization.
Hmm, I automatically think of creating a hash function, but then that's how Python implements keys in dicts, so a dict is fine solution. -- MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
