[Python-Dev] Switch statement

[Josiah Carlson]

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

I'm +1 on alternative 1, but -1 on all others, with a small caveat that
I'll mark with * later on.


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

+1

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

+1 (As I was catching up on the flurry of emails from yesterday this
morning, I noticed to my surprise that you came around to precisely what
I had hoped for in a switch/case statement; I'm going to have to try not
posting on a subject more often <.5 wink>)

> 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.

* I don't particularly care for the literal syntax of static.  I like
the /idea/, but I don't believe that it is as useful as people think it
is.  Let me explain.  Given your previously proposed 'all cases have an
implied static', that handles the switch/case statement, the purpose of
'static' is to explain what happens to the switch/case statement, not
that people would actually use it as such in the switch/case example (as
it is implied, and people are insane about trying to reduce how much
they type).

For general variables, like say; math.pi, re.DOTALL, sys.maxint, len,
int, Exception, etc., many of them are merely references to their values,
that is, there are no value manipulations.  This case is quite
conveniently covered by Raymond's "Decorator for BindingConstants at
compile time", a sexy decorator available in the cookbook [1].  That
decorator can handle all of the non-modifying value assignments, and in
the case of Frederick's previously described:

    if value < const (math.pi / 2):
        ...

... a small modification to Raymond's recipe that allows keyword
arguments (on the decorator) would preserve the beauty of the function
definition, at the cost of an uglier decorator.

    @make_constants(math_pi_2=(math.pi / 2))
    def foo(value):
        if value < math_pi_2:
            ...

Now, it's not as slick as a static unary operator, but it handles the
simple references case quite well, and can be hacked to handle the
saving of expressions without significant difficulty, though such
uglifies the decorator call significantly.  If a variant of that
decorator were available in the standard library, maybe with simple
variants, I believe much of the general talk about 'static' will go away. 
I could certainly be wrong, but that's ok too.


> 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


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

The 'case == X' was cute, though if it was an alternative spelling of
'case X', I doubt it would be used terribly often.  Regardless, I'm -1
on all other cases, and would not be concerned to lose the '== X'
version.

 - Josiah

[1] http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277940