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

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' 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 = which would be similar to = static () but also prevents 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