case/switch statement?
Steven D'Aprano
steve at REMOVETHIScyber.com.au
Sun Jun 12 05:26:02 EDT 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