[Python-Dev] Switch statement

[Guido van Rossum]

On 6/23/06, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> "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.

I'm beginning to lean in that direction myself. A clean rule for
switches would be that if it's not inside a function, the cases must
be compile-time constant expressions.

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

No kidding. There is such a thing as too much heat. I need to do this
more often myself, too!

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

What do you mean by "literal syntax of static"? Do you mean 'static'
<atom> or 'static'  <name> '=' <expression>? Or something else?

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

I'm all for typing less if it makes things clearer for the reader. I'm
not for reductions in what you type at the expense of readability.
Often, reducing redundant boiler plate is of the first category, since
the reader must just skip the boiler plate if it's explicitly typed.

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

But it is an absolutely yucky approach. It modifies byte code. That
makes it break in future Python versions (Python's byte code is not
standardized across versions), as well in Jython, IronPython, and
sandboxed Python (which will make a come-back, see Brett's post).

If it's as valuable as to let people devise the crap in that cookbook
entry (no offense, I'm sure it's a great intellectual accomplishment,
but it's fundamentally the wrong approach) then it's worth adding
something to the language to do it right. As the cookbook discussion
mentions, the decorator assumes that all globals are constant. That is
way too implicit for me.

(IOW, the existence of that cookbook entry proves to me that the
language needs to support something like this explicitly.)

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

Realistically that would be way too verbose. Note how the string
approximating math...pi...2 now occurs three times in the code where
Fredrik's example had it only once!

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

It's fundamentally the wrong approach.

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

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)