[Python-Dev] PEP 3103: A Switch/Case Statement (original) (raw)

Ron Adam rrr at ronadam.com
Tue Jun 27 19:08:01 CEST 2006

Given that variant, my reasons for preferring Option 2 over Option 3 are: - the semantics are the same at module, class and function level - the order of execution roughly matches the order of the source code - it does not cause any surprises when switches are inside conditional logic

As an example of the latter kind of surprise, consider this: def surprise(x): doswitch = False if doswitch: switch x: case sys.stderr.write("Not reachable!\n"): pass Option 2 won't print anything, since the switch statement is never executed, so the jump table is never built. Option 3 (def-time calculation of the jump table), however, will print "Not reachable!" to stderr when the function is defined.

Good points on order of define vs order of execution surprises.

WARNING: probable over generalization below or really usefull idea depending on your point of view. ;)

I use dict base dispatching in a number of my programs and like it with the exception I need to first define all the code in functions (or use lambda) even if they are only one line. So it results in a three step process, define functions, define dict, and then call it. And I need to make sure all the function calls use the same calling signature. In some cases I'm passing variables that one function doesn't need because it is needed in one of the other cases.

So modeling the switch after dictionary dispatching more directly where the switch is explicitly defined first and then used later might be good both because it offers reuse in the current scope and it can easily be used in code that currently uses dict style dispatching.

switch name:
   1:
      ...
   TWO:
      ...
   'a', 'b', 'c':
      ...
   in range(5,10):
      ...
   else:
      ...

for choice in data:
   do choice in name:    # best calling form I can think of.

I think this avoids most of the define time/order and optimization issues as well as the issues I have with dict base dispatching so I thought it might be worth a mention. There may still be some advantage to evaluating the case expressions early, but I think it might not be needed as much in this form so they could be evaluated at switch definition time, which is the order the code is written.

The main arguments against this form might be that it approaches macro and named blocks capabilities a bit too closely, but those may also be arguments for it as this may more directly fulfill the reasons some want named blocks and or macros.

To use a named switch in such a way just call the desired case explicitly ...

 switch responses:
    'make_red':
        ...
    'make_blue':
        ...

 do 'make_red' in responses:
 ...
 do 'make_red' in responses:     # again
 ...
 do 'make_blue' in responses:
 ...

So it offers local reuse of code in a more direct way than a switch statement does and more closely matches that which is current practice with dictionary dispatching.

Cheers, Ron

Just a thought, Ron

More information about the Python-Dev mailing list