1.a lot of 'if'-statement 2.using a dict and the value is a function you call if the key matches
Or what else?
That sounds like a desperate plea to get stuck with a bug-riddled unmaintainable mess of a module.
If all you want to do is pick one of a finite set of possible code paths, it is never a good idea to generate a hash to pick from a map/array.
Even chained if/else if statements are cleaner than that mess.
For a not-small example, if you want to switch on an ascii character in a parser, you can make a 256-element list to implement your jump table, and index into it with ord.
If you're performance-minded enough for this to make a lick of sense, you'll take care to only build the jump table once.
And yeah, chained if/else is cleaner because it's the only tool that the language provides. The GP was asking for alternatives. They exist, but you'll hate them.
Granted, you can speed the 256-long if/elif mess up with a binary if/else tree 8 levels deep. But it probably won't beat the jump table.
If you truly find this upsetting, know that it's a practice that results from the language not supporting a switch statement.
Say you have a program like "docker-compose". It has multiple subcommands. Each subcommand is a dict string key and the appropriate action to take is its value, a callable. This also plays well with argparse's parser "choices" argument.
The by far biggest downside is then that all callables mustn't take arguments, or take all the same ones. You cannot dispatch to a callable and dynamically assign what arguments to call it with without losing the prior benefits. Then it gets awkward (like having to throw around args and kwargs all over the place). But up to that point, I find the pattern useful in this case.