[Python-Dev] PEP 3103: A Switch/Case Statement

[Ron Adam]

> 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):
>       do_switch = False
>       if do_switch:
>           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