[Python-Dev] Switch statement

[Phillip J. Eby]

At 01:08 PM 6/22/2006 +0200, M.-A. Lemburg wrote:
>Phillip J. Eby wrote:
> > Maybe the real answer is to have a "const" declaration, not necessarily 
> the
> > way that Fredrik suggested, but a way to pre-declare constants e.g.:
> >
> >      const FOO = 27
> >
> > And then require case expressions to be either literals or constants.  The
> > constants need not be computable at compile time, just runtime.  If a
> > constant is defined using a foldable expression (e.g. FOO = 27 + 43), then
> > the compiler can always optimize it down to a code level
> > constant.  Otherwise, it can just put constants into cells that the
> > functions use as part of their closure.  (For that matter, the switch
> > statement jump tables, if any, can be put in a cell too.)
> >
> >> I don't like "first use" because it seems to invite tricks.
> >
> > Okay, then I think we need a way to declare a global as being 
> constant.  It
> > seems like all the big problems with switch/case basically amount to us
> > trying to wiggle around the need to explicitly declare constants.
>
>I don't think that this would help us much:
>
>If you want the compiler to "see" that a name binds to a constant,
>it would need to have access to the actual value at compile time
>(e.g. code object definition time).

No, it wouldn't.  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.  ;)


>However, it is common practice to put constants which you'd use
>in e.g. parsers into a separate module and you certainly don't
>want to have the compiler import the module and apply attribute
>lookups.

Not necessary, but I see it does produce a different problem.


>This means that you'd have to declare a symbol constant in the
>scope where you want to use it as such. Which would result in
>long sections of e.g.
>
>const case1
>const case2
>...
>const caseN

Actually, under my proposal it'd be:

const FOO = somemodule.FOO
const BAR = somemodule.BAR

etc.  Which is probably actually worse.  But I see your point.


>In the end, making this implicit in the case part of the switch
>statement would save us a lot of typing.
>
>However, there's another catch: if we do allow arbitrary expressions
>in the case parts we still need to evaluate them at some point:
>
>a. If we do so at compile time, the results may be a lot different
>than at execution time (e.g. say you use time.time() in one of the
>case value expressions).

We can't do that at compile time.

>b. If we evaluate them at code object execution time (e.g. module
>import), then we'd run into similar problems, but at least
>the compiler wouldn't have to have access to the used symbols.
>
>c. If we evaluate at first-use time, results of the evaluation
>become unpredictable and you'd also lose a lot of the
>speedup since building the hash table would consume cycles
>that you'd rather spend on doing other things.

Assuming that a sequential search takes 1/2N equality tests on average, 
you'll come out ahead by the third switch executions, assuming that the 
time to add a dictionary entry or do a hash lookup is roughly equal to an 
if/else test.  The first execution would put N entries in the dictionary, 
and do 1 lookup.  The second execution does 1 lookup, so we're now at N+2 
operations, vs N operations on average for sequential search.  At the third 
execution, we're at N+3 vs. 2.5N, so for more than 6 entries we're already 
ahead.


>d. Ideally, you'd want to create the hash table at compile time
>and this is only possible using literals or by telling the
>compiler to regard a specific set of globals as constant, e.g.
>by passing a dictionary (mapping globals to values) to compile().

I still think that it suffices to assume that an expression produced using 
only symbols that aren't rebound are sufficiently static for use in a case 
expression.  If a symbol is bound by a single import statement (or other 
definition), or isn't bound at all (e.g. it's a builtin), it's easy enough 
to assume that it's going to remain the same.

Combine that compile-time restriction with a first-use build of the 
dictionary, and I think you have the best that we can hope to do in 
balancing implementation simplicity with usefulness and 
non-confusingness.  If it's not good enough, it's not good enough, but I 
don't think there's anything we've thought of so far that comes out with a 
better set of tradeoffs.