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

M.-A. Lemburg mal at egenix.com
Thu Jun 22 13:08:56 CEST 2006

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

More information about the Python-Dev mailing list