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. And if there's an error in the lookup table, well, you look at the normalized version, not at the one that actually gets parsed :) That's basically like looking back at the Python source code rather than the disassembled byte-code; apart from actually debugging the preprocessor itself (which can be done with a ten-entry table that's easily eyeballed), the denormalized version needn't be looked at by a human. But this is a very VERY specific situation. Normally it's best to just use an if/elif block. That's why this looks so "Ewww". :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list