[Python-Dev] Switch statement

Guido van Rossum guido at python.org
Mon Jun 26 22:42:39 CEST 2006

On 6/26/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> In http://mail.python.org/pipermail/python-dev/2006-June/066475.html
> Nick Coghlan wrote:
> > (Unlike Jim, I have no problems with restricting switch statements to
> > hashable objects and building the entire jump table at once - if what you want
> > is an arbitrary if-elif chain, then write one!)
> I haven't been clear.  I don't object to building the entire table at
> once.  I object to promising that this will happen, which forbids
> other implementations from using certain optimizations.
> I would prefer something like:
> There is no guarantee on how often or when the case statements will be
> evaluated, except that it will be after the enclosing scope exists and
> before the relevant test is needed.  If a case expression has side
> effects, the behavior with respect to these side effects is explicitly
> undefined.

This is the kind of language that makes C++ and Fortrans standards so
difficult to interpret. I like Python's rules to be simple, and I
prefer to occasionally close off a potential optimization path in the
sake of simplicity. For example, I like left-to-right evaluation of
operands and function arguments. The C++/Fortran style weasel words to
allow optimizers to do sneaky stuff aren't really wort the trouble
they can create in Python, where even the best optimization produces
code that's much slower than C. In practice, most users observe the
behavior of the one compiler they use, and code to that "standard"; so
allowing different compilers or optimization levels to do different
things when functions have side effects is just asking for surprises.

In Python, the big speedups come from a change in algorithm. That's
why it's imprtant to me that switch be dict-based (O(1)), as an
alternative to an if/elif chain (O(N)). (The implementation doesn't
have to use a regular dict, though; the important part is that it's
based on hash() and __eq__().)

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list