[Python-Dev] Switch statement

[Guido van Rossum]

On 6/21/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 09:16 AM 6/21/2006 -0700, Guido van Rossum wrote:
> >After thinking about it a bit I think that if it's not immediately
> >contained in a function, it should be implemented as alternative
> >syntax for an if/elif chain.
>
> That worries me a little.  Suppose I write a one-off script like this:
>
> for line in sys.stdin:
>      words = line.split()
>      if words:
>          switch words[0]:
>              case "foo": blah
>              case words[-1]: print "mirror image!"

Why would you write a script like that? If you've learned the
"idiomatic" use of a switch statement first, that would never occur to
you. If you're totally clueless, I don't really care that much.

> Then, if I later move the switch into a function, it's not going to mean
> the same thing any more.

And it will be a clear compile-time warning because in the refactored
version you'd be attempting to use a local variable in a case.

> If the values are frozen at first use or
> definition time (which are the same thing for module-level code), then I'll
> find the lurking bug sooner.

Or not, depending on how easily the misbehavior is spotted from a
cursory glance at the output.

> OTOH, breaking it sooner doesn't seem like such a great idea either; seems
> like a recipe for a newbie-FAQ, actually.  ISTM that the only sane way to
> deal with this would be to ban the switch statement at module level, which
> then seems to be an argument for not including the switch statement at all.  :(

I don't understand this line of reasoning. The semantics I propose are
totally well-defined.

> I suppose the other possibility would be to require at compilation time
> that a case expression include only non-local variables.  That would mean
> that you couldn't use *any* variables in a case expression at module-level
> switch, but wording the error message for that to not be misleading might
> be tricky.

That seems overly restrictive given that I expect *most* cases to use
named constants, not literals.

> I suppose an error message for the above could simply point to the fact
> that 'words' is being rebound in the current scope, and thus can't be
> considered a constant.  This is only an error at the top-level if the
> switch appears in a loop, and the variable is rebound somewhere within that
> loop or is rebound more than once in the module as a whole (including
> 'global' assignments in functions).

Let's not focus on the error message. I think your assumption that
every switch at the global level ought to be able to be moved into a
function and work the same way is not a particularly important
requirement.

(As a compromise, a switch at the global level with only literal cases
could be efficiently optimized. This should include "compile-time
constant expressions".)

BTW a switch in a class should be treated the same as a global switch.
But what about a switch in a class in a function?

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