[Python-Dev] Switch statement

[M.-A. Lemburg]

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 ! ::::