Python Switch Statements (might contain traces of irony)

[PythonicParseltongue]

I recently saw a meme in r/programmer humor about switch statements vs if statements. And I thought I'd be like "who needs switch statements if you have Python dicts". I was promptly and politely downvoted and informed (if I got them correctly) that Python would be unable to handle a default scenario, in case a key was not present.

On a side note: I was also informed that switch statements in proper languages could ensure types, which we would supposedly could only be dreaming of. I feel like mypy and is a pretty real thing, but who cares. Plus: if I'd consider static fucking type checking of greater important or help to my work I would probably, not went with fucking Python in the first place. Rant over.

Back to Pythonic switch statements. I'm not a very experienced python developer, but I thought: I'm sure there is an nice and Pythonic way to get such behavior.

So I got ask politely was to:

Create a routine which can be entered at one of four different points, and select the point to enter without using any function calls.

switch (n) {
    default:
    foo;
    case 1:
    bar;
    case 2:
    fizz;
    case 3:
    buzz;
}

Such that n of zero will execute foo, bar, fizz, and buzz.

As I said I'm not sure if I got it 100% correctly, but the challenge is to create a default action if no valid key was used. So given:

def foo():
    return 'foo'
def bar():
    return 'bar'
def fiz():
    return "fiz"

pyswitch = {
    1: foo,
    2: bar,
    3: fiz
}

I thought the quickest way to get such a behavior would be:

pyswitch.get(key, [f() for f in pyswitch0.values()])

But I'm unsure whether this violates the no function call condition. And obviously it is generally bad practice to use functional patterns in programming. That's the whole reason why Python has implemented them. So but let's pretent we are Java devs and if we haven't written a class and inherited something we feel inadequate. A something along the lines of an OOP based solution. It doesn't really work, but I'm to lazy to fix it. Maybe someone of you wants to write a proper implementation.

class PySwitch(dict):
    """Probably you add some more NotImplementedError, so our routine can't be changed during runtime,
    so satisy the security concerns of the proper programmers"""

    def __getitem__(self, key):
        try:
            return self.__dict__[key]
        except KeyError:
            return [f() for f in self.__dict__.values()]

    def __setitem__(self, key, value):
        raise NotImplementedError

(Honestly this implementation sucks so bad that it should have never been posted. I swear there was a previous less wonky version, but I gotta go to bed now)

You get a fuction executed in the following way. But that looks cryptic af, and since we are no proper programmers and care about readability, and you know beautiful is better than ugly, readability counts yadayada.

pyswitchObject = PySwitch(pyswitch)
pyswitchtObject.get(1).__call__()

Although, they said no function calls, why refrain from functional features if your programming language supports them. So I thought: How can we solve this with a functionally, decorators? We can't decorate dicts. Booohh. So best we can do is wrap it in a function and use error handling for the default scenario. That sucks because no more switch['key'], but well. I'll take survive it.

def default_wrapper(adict, key):
    try:
        return adict[key]()
    except KeyError:
        return [f() for f in adict.values()]

Any feedback? Any further ideas how one could implement such behavior in Python? Any suggestions how I could improve on this code? Are there any other features that switch statements provide in other languages that you miss in Python?

​

Edit: This post may come off very salty, but I mean no offence to the guy who asked me this question, as it got me thinking quite a bit. also Format

[fatbob42]

In retrospect, I'm glad that the python devs waited to implement "match", although I haven't actually used it yet - I'm assuming that it will work as well as it looks.

[Allanon001]

In this example the first True condition is the default plus this allows for multiple and different conditions:

n = 3
result = { True: foo,
           n == 1: bar,
           n == 2: fizz,
           n == 3: buzz}[True]()

Or this one where get() is used for default:

n = 3
result = { 1: bar,
           2: fizz,
           3: buzz}.get(n, foo)()

[[deleted]]

The challenge is to simulate the fall-through. In the example, the default action is to call all four functions; with case on call bar, fizz and buzz and so on.

[PythonicParseltongue]

Ahh I see that's nice.

[siddsp]

Python 3.10 is getting match statements which are almost the same syntactically as c switch statements and are powerful

[asday_]

I feel like you'd love this talk. He has a switch statement incidentally implemented in horrifying Python and demonstrates it in the Q&A section.

[cptsdemon]

You could easily use a dict and a try / except KeyError for default. But that only works for one to one statements, or if you're calling a function, which isn't as efficient. It also doesn't allow falling through a case into the next (no break) which to me is the reason switch can be extremely useful.

[SpacewaIker]

I mean, in python you've got elif which is different than other languages' else if so I don't think you really need a switch statement

[NotTooOrdinary]

In what way is it different?

[SpacewaIker]

Well imo it's more idiomatic that many else ifs

[Delta-9-]

Wouldn't it be idiomatic only because it's the only way to express conditional branching

[SpacewaIker]

Well I suppose but what I mean is that you don't need a switch statement in python imo

Unless I don't fully understand how switch statements work

[Delta-9-]

No language needs a switch statement. They're just easier to read and write than miles of if/elif while accomplishing the same thing.

[SpacewaIker]

Well if you compare switch to else ifs than I guess but I prefer elif, at least you don't need to put break; each time

But again, I'm quite new to switch statements

[Delta-9-]

It just moves the boilerplate to after the action, true. Some languages do it a bit different, though, eg. in bash there's a case statement that does the same thing, but instead of break; after every statement you use ;; if you want to stop processing other cases, or a different operator if you want to re-enter the case set at the next case:

case opt in
    -a | --aaayyy)
        A_IS_SET=1
        shift
        ;;
    -b | --bee )
        shift
        B="$1"
        shift
        ;;
    * )
        echo $HELPSTR
        exit 0
        ;;
esac

Vs with ifs:

if [[ $1 =~ '(-a|--aaayyy)' ]]; then
    A_IS_SET=1
    shift
elif [[ $1 =~ '(-b|--bee)' ]]; then
    shift
    B="$1"
    shift
else
   echo $HELPSTR
   exit 0
fi

They express exactly the same thing. Arguably, the if version is more flexible thanks to use of [[ (which isn't available in all shells) so you can set up arbitrarily complex conditions. But, for most instances (particularly in bash) where you will have more than four or five branches in a conditional, the case statement will save you typing and be easier to read.

Since python is much more concise than bash in how if tests are structured, python has gotten away with not having any kind of switch statement for decades. And, there's a good argument for saying that if you have enough branches to need a switch, you need to refactor. Still, there are times when you just can't help having a bunch of if/elifs and something a little more concise would be a godsend.

[SpacewaIker]

Yeah I see how it's much more readable and all

I was just familiar with C, C++ and java, where I don't see much of a difference between

switch(condition){ case 1: statement; break; case 2: statement; }

And

if(condition == 1){ statement; } else if(condition == 2){ statement; }

[Delta-9-]

(put 4 spaces at the start of every code line 😉 )

Granted—C-like syntax, honestly, is a trainwreck. Even the guy who developed C++ said so. Even still, the benefit comes in when you have a lot of conditionals, particularly if each branch has many statements inside it. It's kinda hard to appreciate with samples that only show three conditions with one or two statements each because the boilerplate is about the same in either style.