Python Switch Statement
I think these arguments about whether language X “needs” a switch statement are asking the wrong question.<p>The right question is, “Is language X better for having a switch statement?”<p>Very few control structures are strictly <i>necessary</i> because it is almost always possible to achieve the same thing in a different way. For example, in C, you could rewrite this:<p><pre><code>    while (x &lt; 10) {
        &#x2F;&#x2F; ... some code ...
    }
</code></pre>
To this:<p><pre><code>    goto test;
    begin:
    &#x2F;&#x2F; ... some code ...
    test:
    if (x &lt; 10) {
        goto begin;
    }
</code></pre>
The fact is, there are important differences between a map full of objects and a switch statement. One IMPORTANT difference is that if the switch branches contain references to variables the outer scope, then to convert the switch into a map, you have to  construct the object at least once each time you enter that scope, and the cost of constructing it is proportional to the number of branches. Similarly, if you use a chain of if&#x2F;else statements, then the cost of finding a branch selected uniformly is proportional to the number of branches.<p>With a switch statement, there is normally some kind of assumption that the compiler is capable of optimizing a subset of these use cases—often a well-known or well-understood subset, and that the switch is fast—perhaps similar to a dictionary lookup or table lookup—yet without the cost of constructing a closure for each branch. Even a novice compiler developer can figure out how to make their compiler generate a table for integers or strings.<p>“I’ll just make this control structure out of lambdas” is something that’s theoretically sound, but which may require a much more sophisticated set of optimizations to get similar performance out of.<p>This is not a hypothetical concern—if you want to implement a lexical analyzer or parser, you often want to build it out of big switch statements, especially if the switch statements can be transformed at compile-time into table lookups or something similarly fast. The cost of parsing data, in my experience, can <i>often</i> be a significant fraction of the runtime of the entire program.<p>(If your response is, “Well, why write a parser in Python if you want it to be fast?”, then, well, keep in mind that CPython is not the <i>only</i> Python, and there are many reasons why you would want to write a parser in Python otherwise.)