[Python-Dev] Switch statement

[Alex Martelli]

On 6/22/06, Guido van Rossum <guido at python.org> wrote:
   ...
> (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]

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