[Python-Dev] Switch statement

Fredrik Lundh fredrik at pythonware.com
Thu Jun 22 21:05:15 CEST 2006

Guido van Rossum wrote:

>> well, I find the proposed magic behaviour of "case" at least as confusing...
> It's not magic if it can be explained. "def goes over all the cases
> and evaluates them in the surrounding scope and freezes the meaning of
> the cases that way as long as the function object survives" is not
> magic.

well, people find "def goes over all default values and evaluates them 
in the surrounding scope (etc)" pretty confusing, and the default values 
are all part of the function header.  here you're doing the same thing 
for some expressions *inside* the function body, but not all.  it might 
be easy to explain, but I don't think it's easy to internalize.

> I'm still confused how this wrapper would be used at run time.
> (Because at compile time we *don't* generally know whether a
> particular value contains a const wrapper or not.)

oh, it would require the compiler to check for const-ness on globals 
when the function object is created, which would work for simple names, 
and require some yet-to-be-determined-handwaving-hackery for anything 

>>>>> - local dispatch tables, and other generated-but-static data structures
>>      def foo(value):
>>          table = const {
>>              1: "one",
>>              2: "two",
>>              3: fie.fum,
>>          }
>> (maybe "static" would be a better keyword?)
> At least it resembles the corresponding C keyword better than 'const'.
> 'static' tells me something useful (at least if I know C/C++/Java).
> And I have some idea on how to implement it (not so different from the
> def-time switch freezing).
> However it should be
>   static table = {...}

I'm not sure it should, actually -- the primary form is more flexible, 
and it better matches how things work: it's the expression that's 
special, not the variable.

and things like

     radian = degree * static (math.pi / 180)

would be pretty nice, for those of us who likes our Python fast.

> But I don't see how this would require the const-wrapper.

it wouldn't.

> And I still think that this is not as nice as def-time freezing
> switches; static or const causes clumsy syntax when importing
> constants from another module since you have to repeat the const-ness
> for each imported constant in each importing module.

well, the point is that you only have to spell it out if you actually 
care about things being constant/static/evaluated once/early, and when 
you do, it's always obvious for the reader what you're doing.


More information about the Python-Dev mailing list