Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #104993
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Newsgroups | comp.lang.python |
| Subject | Re: Case Statements |
| Date | 2016-03-16 08:47 +0000 |
| Message-ID | <mailman.183.1458118080.12893.python-list@python.org> (permalink) |
| 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> |
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
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Case Statements jj0gen0info@gmail.com - 2016-03-15 13:46 -0700
Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-15 23:11 +0000
Re: Case Statements jj0gen0info@gmail.com - 2016-03-15 16:47 -0700
Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-15 23:58 +0000
Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 00:51 +0000
Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 01:05 +0000
Re: Case Statements jj0gen0info@gmail.com - 2016-03-15 18:55 -0700
Re: Case Statements "Mario R. Osorio" <nimbiotics@gmail.com> - 2016-03-15 21:06 -0700
Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 10:34 +0000
Re: Case Statements Steven D'Aprano <steve@pearwood.info> - 2016-03-16 23:56 +1100
Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 04:26 +0000
Re: Case Statements Christian Gollwitzer <auriocus@gmx.de> - 2016-03-16 09:13 +0100
Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 08:47 +0000
Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-16 11:16 +0200
Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-16 10:35 +0100
Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 09:51 +0000
Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 19:41 +0000
Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 22:30 +0000
Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-16 11:52 +0100
Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 11:07 +0000
Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 11:16 +0000
Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 11:33 +0000
Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-16 14:21 +0200
Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 12:53 +0000
Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-16 16:31 +0200
Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 15:00 +0000
Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-16 19:07 +0200
Re: Case Statements Rustom Mody <rustompmody@gmail.com> - 2016-03-20 01:01 -0700
Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-20 08:29 +0000
Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-16 14:38 +0100
Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 14:02 +0000
Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-16 21:27 +0200
Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-17 09:22 +0100
Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-17 10:57 +0200
Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-17 10:12 +0100
Re: Case Statements Steven D'Aprano <steve@pearwood.info> - 2016-03-17 11:19 +1100
Re: Case Statements Steven D'Aprano <steve@pearwood.info> - 2016-03-17 12:54 +1100
Re: Case Statements Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-03-17 18:45 +1300
Re: Case Statements Chris Angelico <rosuav@gmail.com> - 2016-03-17 17:30 +1100
Re: Case Statements Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-03-18 18:59 +1300
Re: Case Statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-17 17:29 +1100
Re: Case Statements Chris Angelico <rosuav@gmail.com> - 2016-03-17 17:48 +1100
Re: Case Statements Steven D'Aprano <steve@pearwood.info> - 2016-03-17 21:53 +1100
Re: Case Statements Chris Angelico <rosuav@gmail.com> - 2016-03-17 22:49 +1100
Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-17 10:23 +0100
Re: Case Statements Chris Angelico <rosuav@gmail.com> - 2016-03-17 20:55 +1100
Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-17 09:36 +0100
Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-17 09:38 +0100
Re: Case Statements l0r0m0a0i0l@gmail.com - 2016-03-16 06:15 -0700
Re: Case Statements Steven D'Aprano <steve@pearwood.info> - 2016-03-17 00:27 +1100
Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 14:00 +0000
Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 13:59 +0000
Re: Case Statements l0r0m0a0i0l@gmail.com - 2016-03-16 07:21 -0700
Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-16 16:33 +0200
csiph-web