[Python-Dev] Switch statement (original) (raw)

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