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

Alex Martelli aleaxit at gmail.com
Fri Jun 23 19:08:26 CEST 2006

On 6/22/06, Guido van Rossum <guido at python.org> wrote: ...

(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]

+1, preferably with alternative 1. I've occasionally (ab)used the fact that default values are computed at def time to get similar semantics, but that (whence the "ab") has all sorts of issues (such as "exposing" arguments you really do NOT want to be passed).

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

(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, just because I care about switch only up to a point!-)

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.

Lovely!!! Definitely +1. Could perhaps THIS use of static be allowed even outside of a def? I'd just love to have such static names in modules and classes, too (with runtime checks of errant assignments, if needed).

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. (I'm not counting all the hypergeneralizations that were proposed like case == X: case < X: case is X: case isinstance X: since I'm -1 on all those, no matter how nicely they align.

Agreed on the generalizations, but allowing (just) "case == X" and "case in S" looks more readable to me than "case X" and "case in S". Since I'm not overly focused on switch/case anyway, and this choice is just about syntax sugar anyway, my preference's mild!-)

Alex

More information about the Python-Dev mailing list