case/switch statement?

[Chinook]

On Sun, 12 Jun 2005 17:19:06 -0400, Peter Hansen wrote
(in article <bvidnbXhV-l9OjHfRVn-oQ at powergate.ca>):

> Steven D'Aprano wrote:
>> 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.
>>> It is precisely this behavior that is desired in many situations.  
>> 
>> 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.
> 
> Case statements are actually more suitable in many cases even when 
> performance is not a goal for reasons of *readability*.
> 
> When reading an if statement, you have to scan down through effective 
> each statement attempting to find the case in which you are interested. 
>   Some cases can be compound.  The nested ifs can get confused with the 
> surrounding ones (in Python or a language with explicit block 
> delimiters).  The cases are often not written in any particular order, 
> or they are ordered *for* performance reasons, but in ways that make it 
> harder to "scan".
> 
> A case statement, on the other hand, can be a message from the 
> programmer, saying in effect "here's code that represents a series of 
> _simple_ conditionals, ordered (usually) in a sensible way (e.g. 
> ascending numerical order), so just jump to the case you want and carry 
> on maintaining this nice code."
> 
> In current Python the equivalent approach is, of course, a dictionary of 
> some kind, though it's arguable whether this is as clean in many cases 
> as a case statement would be.
> 
> -Peter
> 

I'm new to Python, but I'm retired from a software engineering career that 
began in the early 60s.  I'm not against case statements in the simplest 
syntactical context, but over the years I've seen so many abuses of such 
(i.e. difficult to follow code) that neither am I against their exclusion 
from Python.  The thought being (in my mind) that such might force the 
programmer to rethink their approach to something more intuitively structured 
(whether module/function wise or OO wise or some combination), though I admit 
it is an idealistic view.  

The problem I do see is your apples and oranges argument.  You are equating 
at the extreme, "compound" if conditions with "_simple_" case statement 
conditionals.  Yet you are leaving out of your argument the transition from 
the former to the latter.  If mapping one to the other is simple then the 
readability is no harder with if statements.  An example might be in dealing 
with variably formated records where each record contains a record type flag. 
 On the other hand if you were to map compound conditions to "_simple_" case 
statement conditionals, you need an intermediate translation that must be 
studied to understand the "_simple_" conditionals anyway.  Such translations 
also promote an overabundance of status/flag variables to understand and 
follow which does not increase the readability of code.  

In my experience I've also seen where case statements promote overly long and 
partially repetitive code blocks, which would be better constructed in a 
top-down fashion.  Admittedly, if statements could be used in a similar way 
but I've not seen the same level of abuse with such.  

So arguably, if the translation is pretty much one to one then the argument 
is mute :~)  If on the other hand the translation is many to one, then one's 
skill in developing well structured readable code is really the issue, and 
again case statements are a mute point.  

Lee C