> On Saturday, November 9, 2013 8:27:02 AM UTC-5, Joshua Landau wrote: > The C switch statement is very limited. The select statement > in the dialect of BASIC I regularly use is more flexible. > It's more concise on long if chains because it elides the "end > if"s. But the use of indentation for blocks and the "in" > operator certainly reduce the need for it in Python.
It's say the C switch isn't limited enough to be a Python resident. The default fallthrough, labels, jumps and breaks make it a poor Python construct. K&R have this to say: "Falling through from one case to another is not robust, being prone to disintegration when the program is modified." So Python would need something simler. Once you winnow it down to a robust feature, it provide virtually nothing you don't get with an if/elif/else. At best it would save a temporary. > The switch statement in (the language) go is similar, except > that <expression0> defaults to true and it doesn't elide > <expression0> in the case statements. Go makes interesting use of switch statements. In addition to what you might expect, you can also do type switches. A type switch lets you provide a different execution path depending on the underlying object represented by an interface. Thus, Go carved out a useful niche for a robust switch statement. Python used duck-typing instead of interfaces and generally doesn't need any special syntax for type checks, hence Go's version of switch doesn't make sense for Python, either. Go's cases must be constants, and allows optional fallthrough with the 'fallthrough' keyword. This forces them to provide break semantics to break out of a switch, which makes using them to break of an immediately outer loop messy. > Dictionaries can't handle the uses where expression0 is > constant and the case expressions are not. Function variables > beg the question. How did you decide what to assign to the > variable? A Python generator might take the place of that application, but I haven't tried it for that. > I'd use this select if it was in Python, but I don't see much > need for it. Same here. Perhaps the real value of a switch is that it seems to be a more natural way of thinking about execution. The caveat to that is most *actual* switch implementations are a mess. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
