3 ms·

So what is the current one and only one pythonic way when you need a switch statement (like having a lot of cases to handle). I see two possibilities: 1.a lot

So what is the current one and only one pythonic way when you need a switch statement (like having a lot of cases to handle). I see two possibilities: 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?

extradesgo 6y ago
I have used this dict solution before in scripts and I am not proud of it.
- staticautomatic 6y ago
  Why not? What’s wrong with this pattern?
  - diarrhea 6y ago
    Not the parent commenter, but I use that pattern all the time, mainly to match CLI flags/args/options to an action. 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.
klyrs 6y ago
There's one that's even closer to c-like switches: a list/tuple of functions or values, indexed by a small int. If you're feeling extremely cheeky, it can even handle negative cases. You'll have to implement fallthrough yourself, though.
- rualca 6y ago
  > There's one that's even closer to c-like switches: a list/tuple of functions or values, indexed by a small int. 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.
  - klyrs 6y ago
    I've seen it used in ways that make sense. They were small and well-contained, and definitely didn't involve computing a hash. 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.
roboticmind 6y ago
I'm not sure that the second option is a very pythonic way to do it, but that's subjective of course. I'd imagine the original commenter views using a lot of ifs and elifs as the pythonic way to do it

extradesgo 6y ago

I have used this dict solution before in scripts and I am not proud of it.

staticautomatic 6y ago
Why not? What’s wrong with this pattern?
- diarrhea 6y ago
  Not the parent commenter, but I use that pattern all the time, mainly to match CLI flags/args/options to an action. 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.

klyrs 6y ago

There's one that's even closer to c-like switches: a list/tuple of functions or values, indexed by a small int. If you're feeling extremely cheeky, it can even handle negative cases. You'll have to implement fallthrough yourself, though.

rualca 6y ago
> There's one that's even closer to c-like switches: a list/tuple of functions or values, indexed by a small int. 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.
- klyrs 6y ago
  I've seen it used in ways that make sense. They were small and well-contained, and definitely didn't involve computing a hash. 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.

roboticmind 6y ago

I'm not sure that the second option is a very pythonic way to do it, but that's subjective of course. I'd imagine the original commenter views using a lot of ifs and elifs as the pythonic way to do it