[Python-Dev] Switch statement

[M.-A. Lemburg]

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

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.

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

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

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.

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

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 22 2006)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2006-07-03: EuroPython 2006, CERN, Switzerland              10 days left

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::