Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info>: > You can't have it both ways: you cannot claim that switch or case is > more readable than a chain of if...elif, and then propose a syntax > which is effectively a chain of if...elif while still claiming it is > an improvement. It's not. All you've done is introduce an element of > implicit magic to the syntax.
You may be right that Python has too many practical problems for a truly fitting switch syntax. > Why (how?) would you want to use *multiple* classes for a single > switch? Well, I was just given a whole link on the very topic: <URL: http://c2.com/cgi/wiki?SwitchStatementsSmell> Here's a shorter one: <URL: http://en.wikipedia.org/wiki/State_pattern> Anyway, while implementing states as singleton inner class instances is elegant and highly readable, the technique suffers in one significant respect: it can be very slow. Often a state machine has numerous states but the typical execution path only visits a few of them. However, the pattern calls for declaring classes (or instances) for all states in the state machine constructor. Switch statements make it possible to avoid this creation overhead. > Dict dispatch tables are elegant, attractive and efficient if you are > using pre-existing functions or functions you can create using lambda: I beg to differ. The dict dispatch tables are very hard to read. The fully blown-out if-else chain beats it in elegance hands down. > There are all sorts of simple and neat ways to handle switches in > Python. That's why the pressure on the language to grow special syntax > is quite low. It simply isn't important enough. Of course the threshold for new syntax should be exceptionally high. Python as a language is already close to the sweet spot. Marko -- https://mail.python.org/mailman/listinfo/python-list
