case/switch statement?

Steven D'Aprano steve at REMOVETHIScyber.com.au
Sun Jun 12 11:26:02 CEST 2005


On Sat, 11 Jun 2005 19:47:58 -0500, Skip Montanaro wrote:

> If the case values are constants known to the compiler, it can generate O(1)
> code to take the correct branch.  (In fact, that could be done by the
> compiler for if statements such as in your example today.  It just isn't.)
> It is precisely this behavior that is desired in many situations.  See PEP
> 275 for details:

Agreed. I certainly don't object to sensible optimizations! But the number
of if...elif statements which can be optimised are a vanishingly small
subset of the number of possible if...elif statements.

And you can bet your last dollar that many people will use case statements
even when doing so gives no advantage, in a mistaken opinion that it will
be somehow magically faster.

In fact, some languages even encourage this: I recall the old 4GL (back in
the early 1990s when developers actually used the term Fourth Generation
Language unselfconsciously) used to develop the spreadsheet "Wingz". It
included two different forms for case. By memory:

case EXPR of:
    VALUE:
        SUITE
    VALUE:
        SUITE
    otherwise:
        SUITE

(which could potentially be optimised) and a second form:

case:
    EXPR of:
        SUITE
    EXPR of:
        SUITE
    otherwise:
        SUITE

which was almost certainly nothing more than syntactic sugar for:

if EXPR then:
    SUITE
else if EXPR then:
    SUITE
else:
    SUITE

In any case, even when case statements can be optimized (and we all know
the lesson about premature optimization), the original poster's complaint
appeared to be purely a stylistic issue: he didn't relish using long
if..elif statements. Who does? Not I. My comment, I hope, will remind
folks that long pieces of branching code are ugly regardless of which
syntax you use.


-- 
Steven.






More information about the Python-list mailing list