Alternative 1

This is the preferred form in PEP 275:

switch EXPR:
    case EXPR:
        SUITE
    case EXPR:
        SUITE
    ...
    else:
        SUITE

The main downside is that the suites where all the action is are indented two levels deep; this can be remedied by indenting the cases “half a level” (e.g. 2 spaces if the general indentation level is 4).

Alternative 2

This is Fredrik Lundh’s preferred form; it differs by not indenting the cases:

switch EXPR:
case EXPR:
    SUITE
case EXPR:
    SUITE
....
else:
    SUITE

Some reasons not to choose this include expected difficulties for auto-indenting editors, folding editors, and the like; and confused users. There are no situations currently in Python where a line ending in a colon is followed by an unindented line.

Alternative 3

This is the same as alternative 2 but leaves out the colon after the switch:

switch EXPR
case EXPR:
    SUITE
case EXPR:
    SUITE
....
else:
    SUITE

The hope of this alternative is that it will not upset the auto-indent logic of the average Python-aware text editor less. But it looks strange to me.

Alternative 4

This leaves out the ‘case’ keyword on the basis that it is redundant:

switch EXPR:
    EXPR:
        SUITE
    EXPR:
        SUITE
    ...
    else:
        SUITE

Unfortunately now we are forced to indent the case expressions, because otherwise (at least in the absence of an ‘else’ keyword) the parser would have a hard time distinguishing between an unindented case expression (which continues the switch statement) or an unrelated statement that starts like an expression (such as an assignment or a procedure call). The parser is not smart enough to backtrack once it sees the colon. This is my least favorite alternative.

Alternative A

Use:

case EXPR:

to match on a single expression; use:

case EXPR, EXPR, ...:

to match on multiple expressions. The is interpreted so that if EXPR is a parenthesized tuple or another expression whose value is a tuple, the switch expression must equal that tuple, not one of its elements. This means that we cannot use a variable to indicate multiple cases. While this is also true in C’s switch statement, it is a relatively common occurrence in Python (see for example sre_compile.py).

Alternative B

Use:

case EXPR:

to match on a single expression; use:

case in EXPR_LIST:

to match on multiple expressions. If EXPR_LIST is a single expression, the ‘in’ forces its interpretation as an iterable (or something supporting __contains__, in a minority semantics alternative). If it is multiple expressions, each of those is considered for a match.

Alternative C

Use:

case EXPR:

to match on a single expression; use:

case EXPR, EXPR, ...:

to match on multiple expressions (as in alternative A); and use:

case *EXPR:

to match on the elements of an expression whose value is an iterable. The latter two cases can be combined, so that the true syntax is more like this:

case [*]EXPR, [*]EXPR, ...:

The * notation is similar to the use of prefix * already in use for variable-length parameter lists and for passing computed argument lists, and often proposed for value-unpacking (e.g. a, b, *c = X as an alternative to (a, b), c = X[:2], X[2:]).

Alternative D

This is a mixture of alternatives B and C; the syntax is like alternative B but instead of the ‘in’ keyword it uses ‘*’. This is more limited, but still allows the same flexibility. It uses:

case EXPR:

to match on a single expression and:

case *EXPR:

to match on the elements of an iterable. If one wants to specify multiple matches in one case, one can write this:

case *(EXPR, EXPR, ...):

or perhaps this (although it’s a bit strange because the relative priority of ‘*’ and ‘,’ is different than elsewhere):

case * EXPR, EXPR, ...:

Discussion

Alternatives B, C and D are motivated by the desire to specify multiple cases with the same treatment using a variable representing a set (usually a tuple) rather than spelling them out. The motivation for this is usually that if one has several switches over the same set of cases it’s a shame to have to spell out all the alternatives each time. An additional motivation is to be able to specify ranges to be matched easily and efficiently, similar to Pascal’s “1..1000:” notation. At the same time we want to prevent the kind of mistake that is common in exception handling (and which will be addressed in Python 3000 by changing the syntax of the except clause): writing “case 1, 2:” where “case (1, 2):” was meant, or vice versa.

The case could be made that the need is insufficient for the added complexity; C doesn’t have a way to express ranges either, and it’s used a lot more than Pascal these days. Also, if a dispatch method based on dict lookup is chosen as the semantics, large ranges could be inefficient (consider range(1, sys.maxint)).

All in all my preferences are (from most to least favorite) B, A, D’, C, where D’ is D without the third possibility.

If/Elif Chain vs. Dict-based Dispatch

There are several main schools of thought about the switch statement’s semantics:

• School I wants to define the switch statement in term of an equivalent if/elif chain (possibly with some optimization thrown in).
• School II prefers to think of it as a dispatch on a precomputed dict. There are different choices for when the precomputation happens.
• There’s also school III, which agrees with school I that the definition of a switch statement should be in terms of an equivalent if/elif chain, but concedes to the optimization camp that all expressions involved must be hashable.

We need to further separate school I into school Ia and school Ib:

• School Ia has a simple position: a switch statement is translated to an equivalent if/elif chain, and that’s that. It should not be linked to optimization at all. That is also my main objection against this school: without any hint of optimization, the switch statement isn’t attractive enough to warrant new syntax.
• School Ib has a more complex position: it agrees with school II that optimization is important, and is willing to concede the compiler certain liberties to allow this. (For example, PEP 275 Solution 1.) In particular, hash() of the switch and case expressions may or may not be called (so it should be side-effect-free); and the case expressions may not be evaluated each time as expected by the if/elif chain behavior, so the case expressions should also be side-effect free. My objection to this (elaborated below) is that if either the hash() or the case expressions aren’t side-effect-free, optimized and unoptimized code may behave differently.

School II grew out of the realization that optimization of commonly found cases isn’t so easy, and that it’s better to face this head on. This will become clear below.

The differences between school I (mostly school Ib) and school II are threefold:

• When optimizing using a dispatch dict, if either the switch expression or the case expressions are unhashable (in which case hash() raises an exception), school Ib requires catching the hash() failure and falling back to an if/elif chain. School II simply lets the exception happen. The problem with catching an exception in hash() as required by school Ib, is that this may hide a genuine bug. A possible way out is to only use a dispatch dict if all case expressions are ints, strings or other built-ins with known good hash behavior, and to only attempt to hash the switch expression if it is also one of those types. Type objects should probably also be supported here. This is the (only) problem that school III addresses.
• When optimizing using a dispatch dict, if the hash() function of any expression involved returns an incorrect value, under school Ib, optimized code will not behave the same as unoptimized code. This is a well-known problem with optimization-related bugs, and waste lots of developer time. Under school II, in this situation incorrect results are produced at least consistently, which should make debugging a bit easier. The way out proposed for the previous bullet would also help here.
• School Ib doesn’t have a good optimization strategy if the case expressions are named constants. The compiler cannot know their values for sure, and it cannot know whether they are truly constant. As a way out, it has been proposed to re-evaluate the expression corresponding to the case once the dict has identified which case should be taken, to verify that the value of the expression didn’t change. But strictly speaking, all the case expressions occurring before that case would also have to be checked, in order to preserve the true if/elif chain semantics, thereby completely killing the optimization. Another proposed solution is to have callbacks notifying the dispatch dict of changes in the value of variables or attributes involved in the case expressions. But this is not likely implementable in the general case, and would require many namespaces to bear the burden of supporting such callbacks, which currently don’t exist at all.
• Finally, there’s a difference of opinion regarding the treatment of duplicate cases (i.e. two or more cases with match expressions that evaluates to the same value). School I wants to treat this the same is an if/elif chain would treat it (i.e. the first match wins and the code for the second match is silently unreachable); school II wants this to be an error at the time the dispatch dict is frozen (so dead code doesn’t go undiagnosed).

School I sees trouble in school II’s approach of pre-freezing a dispatch dict because it places a new and unusual burden on programmers to understand exactly what kinds of case values are allowed to be frozen and when the case values will be frozen, or they might be surprised by the switch statement’s behavior.

School II doesn’t believe that school Ia’s unoptimized switch is worth the effort, and it sees trouble in school Ib’s proposal for optimization, which can cause optimized and unoptimized code to behave differently.

In addition, school II sees little value in allowing cases involving unhashable values; after all if the user expects such values, they can just as easily write an if/elif chain. School II also doesn’t believe that it’s right to allow dead code due to overlapping cases to occur unflagged, when the dict-based dispatch implementation makes it so easy to trap this.

However, there are some use cases for overlapping/duplicate cases. Suppose you’re switching on some OS-specific constants (e.g. exported by the os module or some module like that). You have a case for each. But on some OS, two different constants have the same value (since on that OS they are implemented the same way – like O_TEXT and O_BINARY on Unix). If duplicate cases are flagged as errors, your switch wouldn’t work at all on that OS. It would be much better if you could arrange the cases so that one case has preference over another.

There’s also the (more likely) use case where you have a set of cases to be treated the same, but one member of the set must be treated differently. It would be convenient to put the exception in an earlier case and be done with it.

(Yes, it seems a shame not to be able to diagnose dead code due to accidental case duplication. Maybe that’s less important, and pychecker can deal with it? After all we don’t diagnose duplicate method definitions either.)

This suggests school IIb: like school II but redundant cases must be resolved by choosing the first match. This is trivial to implement when building the dispatch dict (skip keys already present).

(An alternative would be to introduce new syntax to indicate “okay to have overlapping cases” or “ok if this case is dead code” but I find that overkill.)

Personally, I’m in school II: I believe that the dict-based dispatch is the one true implementation for switch statements and that we should face the limitations up front, so that we can reap maximal benefits. I’m leaning towards school IIb – duplicate cases should be resolved by the ordering of the cases instead of flagged as errors.

When to Freeze the Dispatch Dict

For the supporters of school II (dict-based dispatch), the next big dividing issue is when to create the dict used for switching. I call this “freezing the dict”.

The main problem that makes this interesting is the observation that Python doesn’t have named compile-time constants. What is conceptually a constant, such as re.IGNORECASE, is a variable to the compiler, and there’s nothing to stop crooked code from modifying its value.

def foo(x, y):
    switch x:
    case y:
        print 42

def foo(x, y):
    if x == y:
        print 42