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

Josiah Carlson jcarlson at uci.edu
Fri Jun 23 18:28:44 CEST 2006

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

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 = which would be similar to = static () but also prevents from being assigned to elsewhere in the same scope.

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.

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

More information about the Python-Dev mailing list