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

Guido van Rossum guido at python.org
Mon Jun 19 22:29:55 CEST 2006

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... srecompile.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: handleeven() case 1, 3, 5, 9: handleodd() default: handlefractions()

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): handleodd() case xrange(1,sys.maxint,2): handleeven() default: handlefractions()

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 srecompile.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/)

More information about the Python-Dev mailing list