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. -- http://mail.python.org/mailman/listinfo/python-list