[Python-Dev] Switch statement

[Guido van Rossum]

On 6/22/06, Fredrik Lundh <fredrik at pythonware.com> wrote:
> Guido van Rossum wrote:
> > 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.

I think it's more surprising than confusing, in the same way as
mutable class variables are, or the sharing that follows from "a = [];
b = a".

The switch proposal has less opportunity for this particular surprise
because the case expressions must be immutable (or at least hashable,
which pretty much boils down to the same thing).

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

It's hard to see how it will lead to actual surprises given even only
moderately decent coding style (which would imply not changing global
variables as implied "parameters").

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

I'd like to see more examples that show how it works. Some simple
"this works, that doesn't, because..." demos.

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

OK, I think I see how this works. You pre-compute the expression at
def-time, squirrel it away in a hidden field on the function object,
and assign it to a local each time the statement is executed. So this
would be allowed?

  a = static 1
  a = static 2  # same variable

> and things like
>
>      radian = degree * static (math.pi / 180)
>
> would be pretty nice, for those of us who likes our Python fast.

No argument there.

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

Unfortunately this would probably cause people to write

  switch x:
    case static re.DOTALL: ...
    case static re.IGNORECASE: ...

which is just more work to get the same effect as the
def-time-switch-freezing proposal.

I'm also unclear on what you propose this would do *without* the
statics. Would it be a compile-time error? Compile the dict each time
the switch is executed? Degenerate to an if/elif chain? Then what if x
is unhashable? What if *some* cases are static and others aren't?

Also, do you still see any use for the const wrapper that you brought
up earlier? I don't at this point.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)