On 6/28/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Phillip J. Eby wrote: > > > Hear, hear! We already have if/elif, we don't need another way to spell > > it. The whole point of switch is that it asserts that exactly *one* case > > is supposed to match > > that's not true for all programming languages that has a switch construct, > though; > the common trait is that you're dispatching on a single value, not > necessarily that > there cannot be potentially overlapping case conditions.
You have a point. Suppose you're switching on some os-specific constants (e.g. exported by the os module or some module like that). You have a case for each. But on some os, two different constants have the same value (since on that os they are implemented the same way -- like O_TEXT and O_BINARY on Unix). Now your switch wouldn't work at all on that os; it would be much better if you could arrange the cases so that one case has preference over another. There's also the (more likely) use case where you have a set of cases to be treated the same, but one member of the set must be treated differently. It would be convenient to put the exception in an earlier case and be done with it. Yet, it seems a shame not to be able to diagnose dead code due to accidental case duplication. Maybe that's less important, and pychecker can deal with it? After all we don't diagnose duplicate method definitions either, and that must have bitten many of us (usually due to a copy-and-paste error)... This doesn't move me to school I. But I do want to introduce school IIb which resolves redundant cases by saying the first match wins. This is trivial to implement when building the dispatch dict (skip keys already present). (An alternative would be to introduce new syntax to indicate "okay to have overlapping cases" or "ok if this case is dead code" but I find that overkill.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
