[Python-Dev] Switch statement

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:
 ...
 else:
 ...
to
 VAR = EXPR
 if VAR == E1:
 ...
 elif VAR in E2:
 ...
 else:
 ...
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.
</F>