Guido van Rossum wrote: >> 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. that can happen to the best of us ;-) > 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. same approach as for try/except, in other words. > 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)... we could use a warning for this... > 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). I just wish I could figure out what school my original micro-PEP belongs to (but as long as my implementation note is still just a draft, I guess no- body else can figure that out either... ;-) </F>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4