[Python-Dev] Switch statement

[Guido van Rossum]

On 6/19/06, Raymond Hettinger <rhettinger at ewtllc.com> wrote:
[Guido]
> > I'm not so sure about there being no hidden surprises. I betcha that
> > there are quire a few bits of code that curerntly use the if/elif
> > style and seem to beg for a switch statement that depend on the
> > ordering of the tests. A typical example would be to have one of the
> > earlier tests express an exception to a later test that is a range
> > test.
>
> That's a tricky issue.  Whenever the cases overlap, I would expect a
> successive comparison approach to jump to the first match while a hash
> table approach would jump to the last match (just like a dictionary
> retains only the latest (key,value) pair when fed successive pairs with
> identical keys and differing values).

But it would be easy enough to define a dict-filling function that
updates only new values. (PyDict_Merge has an option to do this,
although it's not currently exposed to Python.)

> > (Surely we're going to support range tests... sre_compile.py
> > uses 'in' almost as often as 'is'.)
>
> When the ranges have a short length as they do in sre, I expect that the
> syntax would allow the range to be captured on one line but have
> multiple entries in the hash table which each dispatch to the same
> target code suite:
>
>     switch x:
>     case 0, 2, 4, 6:  handle_even()
>     case 1, 3, 5, 9:  handle_odd()
>     default:  handle_fractions()

Was it decided yet how to write the cases for a switch that tests for
tuples of values? Requiring parentheses might be sufficient,
essentially making what follows a case *always* take on sequence
syntax.

> Unfortunately, that approach is less than ideal for bigger ranges:
>
>    switch x:
>    case xrange(0,sys.maxint,2): handle_odd()
>    case xrange(1,sys.maxint,2): handle_even()
>    default: handle_fractions()

Right. This would be fine syntactically but clearly breaks the dict
implementation...

> Other types of range checks get us back into the area of arbitrary
> expressions in case values and having to repeat the variable name:
>
>    switch x:
>    case x < 60:  return "too cold"
>    case 60 <= x < 80:  return "just right"
>    case 80 <= x: return "too hot"
>
> Choose your poison.  How much range flexibility do you want and how much
> implementation and behavioral complexity are you willing to pay for it.

In order to decide, we should look at current usage of long if/elif chains.

> >> If use cases eventually emerge for an alternative path using successive
> >> == comparisons, then it can always be considered and added later.  For
> >> now, YAGNI (neither the functionality, nor the implementation headaches,
> >> nor the complexity of explaining what it does under all the various
> >> cases).
> >
> > I say, let someone give a complete implementation a try, and then try
> > to modify as much standard library code as possible to use it. Then
> > report back. That would be a very interesting experiment to do. (And
> > thanks for the pointer to sre_compile.py as a use case!)
>
> Hmm, it could be time for the Georg bot to graduate to big game.
> Georg, are you up to it?

Georg is a bot? :-)

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