
Pythonic switch statement - luord
https://aroberge.blogspot.com/2018/06/pythonic-switch-statement.html
======
aroberge
Author of the blog post here: this is just me having fun with import hooks in
Python. The code written for this specific example is just a quick prototype
which should not be used as an example for anything serious.

Still ... it's fun! ;-)

------
wilkystyle
I was just reading about switch/case in Python yesterday, and came across the
following SO post:

[https://stackoverflow.com/a/46701087/1867039](https://stackoverflow.com/a/46701087/1867039)

The gist of that answer is that switch/case is not implemented in Python
because there is no way to generate an efficient jump table (due to lack of
ability to declare constants); given that limitation, any attempts thus far
haven't added any benefit over if/elif/else or dictionary dispatch (I am a fan
of the latter, personally).

EDIT: Grammar.

------
ant6n
Not sure whether the flow-through on cases is very Pythonic.

~~~
aroberge
Given that Python has "break" as a keyword and "Explicit is better than
implicit", I thought it was Pythonic to have it this way.

~~~
laurentlb
If the code implicitly executes the next block (unless there's a `break`), I
don't think it's better.

* Option 1. To be more explicit, require that each block ends with break or continue.

* Option 2. Use continue (or fallthrough as in Go) to execute the next block. Otherwise, it exits the block.

* Option 3. Support neither continue, nor break. Each block is independent from each other and there's no way to continue to the next block.

I'd personally go with Option 3. This means that break/continue can be used
inside the switch to break/continue an enclosing loop. I don't think the
missing feature is a big miss anyway.

~~~
milesvp
Let's not forget that for C style switch statements, the implicit fallthrough
is often sited as a bug (though it looks to have been influenced by fortran's
computed GOTO, so certainly there was earlier precedent).

I will tell you having done over a decade of maintenance programming. The
absolute worse thing you can do is have implicit fallthrough. Bugs of omission
are the hardest to fix, since it's unclear what the original intended behavior
was supposed to be, let alone whether the code is actually doing what it's
supposed to. Basically there are three things you have to figure out when
working with other's code, you have to figure out: what the code is doing,
what the code is supposed to be doing, and what the original author thought
the code was doing. What often happens, is you find a piece of code that looks
like it's a bug, but it turns out that there's some edge case that requires a
piece of code to look like it does (and maybe the current bug is less severe
than the edge case that it deals with). Something like a missing break can be
one of the hardest things to reason about in code, because it's unclear if the
author knew something about each case than me, or if they just forgot to put
one.

Personally, I support neither continue, nor break. Code duplication is not as
big a sin as most programmers feel it is. But I can appreciate an explicit
continue, since it's a useful enough construct for people to keep implementing
fallthrough. I also might vote for a new keyword other than continue, since
continue fells slightly overloaded in this context.

