[Python-Dev] Switch statement

[Phillip J. Eby]

At 09:37 AM 6/22/2006 -0700, Guido van Rossum wrote:
>On 6/22/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> > This hypothetical "const" would be a *statement*,
> > executed like any other statement.  It binds a name to a value -- and
> > produces an error if the value changes.  The compiler doesn't need to know
> > what it evaluates to at runtime; that's what LOAD_NAME or LOAD_DEREF are
> > for.  ;)
>
>Please think this through more. How do you implement the "produces an
>error if the value changes" part? Is the const property you're
>thinking of part of the name or of the object it refers to?
>
>The only way I can see it work is if const-ness is a compile-time
>property of names, just like global. But that requires too much
>repetition when a constant is imported.

Right; MAL pointed that out in the message I was replying to, and I 
conceded his point.  Of course, if you consider constness to be an implicit 
property of imported names that aren't rebound, the repetition problem goes 
away.

And if you then require all "case" expressions to be either literals or 
constant names, we can also duck the "when does the expression get 
evaluated?" question.  The obvious answer is that it's evaluated wherever 
you bound the name, and the compiler can either optimize the switch 
statement (or not), depending on where the assignment took place.  A switch 
that's in a loop or a function call can only be optimized if all its 
constants are declared outside the loop or function body; otherwise it 
degrades to an if/elif chain.

There's actually an in-between possibility, too: you could generate if's 
for constants declared in the loop or function body, and use a dictionary 
for any literals or constants declared outside the loop or function 
body.  The only problem that raises is the possibility of an "inner 
constant" being equal to an "outer constant", creating an ambiguity.  But 
we could just say that nearer constants take precedence over later ones, or 
force you to introduce the cases such that inner constants appear first.

(This approach doesn't really need an explicit "const foo=bar" declaration, 
though; it just restricts cases to using names that are bound only once in 
the code of the scope they're obtained from.)