New user's initial thoughts / criticisms of Python

[Chris Angelico]

On Mon, Nov 11, 2013 at 10:17 PM, Steven D'Aprano
<steve+comp.lang.python at 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