[Python-Dev] Switch statement

Fredrik Lundh fredrik at pythonware.com
Fri Jun 23 10:01:34 CEST 2006

Guido van Rossum wrote:

> That sounds like a good solution all around. I hope that others can
> also find themselves in this.
> (1) An expression of the form 'static' <atom> has the semantics of
> evaluating the atom at the same time as the nearest surrounding
> function definition. If there is no surrounding function definition,
> 'static' is a no-op and the expression is evaluated every time.
> [Alternative 1: this is an error] [Alternative 2: it is evaluated
> before the module is entered; this would imply it can not involve any
> imported names but it can involve builtins] [Alternative 3:
> precomputed the first time the switch is entered]

+0.5 on this (still looking for some obvious drawback).

as for static in non-local scopes, an error feels more pythonic, but 
that would complicate things if you want to move code from a local to a 
global context (but how often do you do that ?).  alternative 2 and 3 
feels "too magic", again.

> (2) All case expressions in a switch have an implied 'static'.

I'm still -0 on implied static.  and only +0 on switch/case, in general. 
  but it's growing on me.

(now, if you're written "implied 'break'", I'm all for it)

> (3) A switch is implemented using a dict which is precomputed at the
> same time its static expressions are precomputed. The switch
> expression must be hashable. Overlap between different cases will
> raise an exception at precomputation time.

+0 on switch/case, but -0.5 on a "in terms of implementation" rather 
than "in terms of existing language constructs" approach.

as I mentioned before, I'd prefer if the switch/case/case-in/else was 
defined in terms of a corresponding if/elif/else construct (but where 
the controlling expression is only evaluated once).

after all, Python's a dynamic language, and I'm not convinced that I 
would never want to use dynamically evaluated case values.  just map

     switch EXPR:
     case E1:
     case in E2:


     VAR = EXPR
     if VAR == E1:
     elif VAR in E2:

where VAR is a temporary variable, and case and case-in clauses can be 
freely mixed, and leave the rest to the code generator.  (we could even 
allow "switch EXPR [as VAR]" to match a certain other sugar construct).

I'm also a K&R guy, so switch/case/case-in/else should all have the same 
indent.  anything else is just sloppy design.

> Independent from this, I wonder if we also need static names of the form
>   static <name> = <expression>
> which would be similar to
>   <name> = static (<expression>)
> but also prevents <name> from being assigned to elsewhere in the same scope.

-0 from here; I don't see an obvious need for static names, but it may 
grow on me.

> Also, I haven't heard a lot of thumbs up or down on the idea of using
>   case X:
> to indicate a single value and
>   case in S:
> to indicate a sequence of values.

+1 from here.  it's obvious, useful, and therefore perfectly pythonic.


More information about the Python-Dev mailing list