Nick Coghlan wrote: > M.-A. Lemburg wrote: >> The standard >> >> if ... >> elif ... >> efif ... >> else: >> ... >> >> scheme already provides the above logic. There's really >> no need to invent yet another syntax to write such >> constructs, IMHO. > > It's a DRY thing.
Exactly, though not in the sense you are suggesting :-) The motivation for the PEP 275 is to enhance performance when switching on multiple values with these values being constants. I don't want to repeat the discussion here. Please see the PEP for details: http://www.python.org/dev/peps/pep-0275/ Note that the PEP is entitled "Switching on Multiple Values". Adding a switch statement is only one of the two proposed solutions. My personal favorite is making the compiler smarter to detect the mentioned if-elif-else scheme and generate code which uses a lookup table for implementing fast branching. The main arguments for this solution are: * existing code can benefit from the optimization * no need for new keywords * code written for Python 2.6 will be executable by earlier Python versions as well > The construct that a switch statement can replace > actually needs to be written: > > v = ... > if v == ...: > ... > elif v == ...: > ... > elif v == ...: > ... > else: > ... > > The 'v =' part is replaced by 'switch' and the 'if v ==' and 'elif v ==' > are all replaced by 'case'. Actually, there's one more contraint: the ... part on the right needs to be constant - at least if you use the same motiviation as in the PEP 275. > A separate statement is also easier to document to say that order of > evaluation of the cases is not guaranteed, and that the cases may only > be evaluated once and cached thereafter, allowing us free rein for > optimisations that aren't possible with a normal if statement. No need for any caching magic: the values on which you switch will have to be constants anyway. > The optimisation of the if-elif case would then simply be to say that the > compiler can recognise if-elif chains like the one above where the RHS > of the comparisons are all hashable literals and collapse them to switch > statements. Right (constants are usually hashable :-). > It's also worth thinking about what a 'missing else' might mean for a > switch statement. Should it default to "else: pass" like other else > clauses, or does it make more sense for the default behaviour to be > "else: raise ValueError('Unexpected input to switch statement')", with > an explicit "else: pass" required to suppress the exception? Good point. I'd say it's a SyntaxError not to provide an else part. That way you leave the decision to raise an exception or not to the programmer. > The lack of a switch statement doesn't really bother me personally, > since I tend to just write my state machine type code so that it works > off a dictionary that I define elsewhere, but I can see the appeal of > having one, *if* there are things that we can do with a separate > statement to make it *better* for the purpose than a simple if-elif > chain or a predefined function lookup dictionary. The problem with a dispatch approach is that Python function or method calls take rather long to setup and execute. If you write things like parsers, you typically have code that only does very few things per switch case, e.g. add the data to some list - the function call overhead pretty much kills the dispatch approach compared to the O(n) approach using if-elif-chains. Dispatching is useful in situations where you do lots of complicated things for each case. The function call overhead then becomes negligible. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 15 2006) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2006-07-03: EuroPython 2006, CERN, Switzerland 17 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________ 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
