Path: csiph.com!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: Mark Lawrence <breamoreboy@yahoo.co.uk>
Newsgroups: comp.lang.python
Subject: Re: Case Statements
Date: Wed, 16 Mar 2016 08:47:08 +0000
Lines: 111
Message-ID: <mailman.183.1458118080.12893.python-list@python.org>
References: <f30500db-19cb-4de8-81f1-6eb77c28b3b4@googlegroups.com> <30502a2e-0bad-4b0f-a1e8-a2b40b0d7ab9@googlegroups.com> <mailman.181.1458102409.12893.python-list@python.org> <ncb4e0$op1$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
In-Reply-To: <ncb4e0$op1$1@dont-email.me>
Precedence: list
Xref: csiph.com comp.lang.python:104993

On 16/03/2016 08:13, Christian Gollwitzer wrote:
> Am 16.03.16 um 05:26 schrieb Mark Lawrence:
>> So you would rather write something like:-
>>
>> switch (x):
>>    case COW:
>>      moo()
>>      break
>>
>>    case DUCK:
>>      quack()
>>      break
>>
>>    default IDUNNO:
>>      panic()
>>
>> than:-
>>
>> x.makeNoise()
>
> No sane person would do that. But just because you selected the worst
> possible semantics (fallthrough/break) and the worst posible use case
> (simulating polymorphism) doesn't mean that switches have no use. Code
> like the above was used a lot in early GUI toolkits for C - Motif and
> the Windows C API, for instance, use a gigantic switch to decide upon
> incoming events. Now the strange statement in the switch discussion
> makes sense:

I've never said that switches have no use. As the powers to be have 
decreed that they're not going into Python, and I fully agree with that 
decision, I just wish people would shut up about them, but the issue 
keeps cropping up.

>
> "Typically, similar switch statements are scattered throughout a
> program. If you add or remove a clause in one switch, you often have to
> find and repair the others too."
>
> That happens indeed if one were to simulate polymorphism using switch
> statements, but not for other cases.
>
> In Python, you need to go the other way round, you don't have a switch,
> but you can simulate it via function tables or polymorphism.
> The difference between a switch and its simulation via function pointer
> tables etc. is the scope. In a true switch statement, the code blocks
> access the same variables. You can't truly simulate an if statement in
> Python, if it were missing:

I've no idea at all what you mean by the above.

>
>  >>> def hi():
> ...  print "hi"
> ...
>  >>> def yu():
> ...  print "yu"
> ...
>  >>> hi() if 1>2 else yu()
> yu
>  >>> hi() if 2>1 else yu()
> hi
>
> This gives you, in principal, an if-then-else statement back. But you
> can't do something like
>
> if 1>2:
>    a=3
> else:
>    b=2

The above appears to have crept into Python when you weren't looking.

C:\Users\Mark\Documents\MyPython>py -3
Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> if 1>2:
...   a=2
... else:
...   b=3
...
 >>> a
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined
 >>> b
3

>
> Same with switch. You can use a hash table etc. to simulate switches,
> but only if the codeblocks are independent. Otherwise, if-elif chains
> are the way to go. Command line parsing is a case where switch
> statements are often used, e.g. in shell scripts.

I've seen at least six different ways of simulating switches, so those 
people who want them, can have them.  if-elif chains are not likely to 
kill any Python programmer.

I have no interest what other languages use switch/case statements for, 
as we've on the PYTHON mailing list.

>
>      Christian


-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence