[Python-Dev] Switch statement - handling errors

[Jim Jewett]

On 6/26/06, Guido van Rossum <guido at python.org> wrote:
> I like Python's rules to be simple, and I
> prefer to occasionally close off a potential optimization path in the
> sake of simplicity.

(Almost) everyone agrees that the case expressions SHOULD be run-time
constants.  The disagreements are largely over what to do when this
gets violated.


Bad Case Option (1) -- Accept everything
----------------------------------------

Readability is everything.  Switch/case tells you that every branch is
using similar predicates on the same variable.  If that variable or
predicate can't be easily optimized, then so what -- it is still
better to read.  (Largely School Ia)


Bad Case Option (2) -- Accept very little
-----------------------------------------

Enforce good case expressions.  (Raymond's proposal)  This does the
right thing when it works, but it is initially very restricted -- and
a crippled case statement may be worse than none at all.


Bad Case Option (3) -- Raise Exceptions
---------------------------------------

Flag bugs early.  The semantics require non-overlapping hashable
constants, so raise an exception if this gets violated.  This does the
right thing, but catching all the violations in a timely manner is
hard.

Freezing at first use is too late for a good exception, but any
earlier has surprising restrictions.

There is no good way to realize that a "constant" has changed after the freeze.


Bad Case Option (4) -- Ignore problems
--------------------------------------

This is for optimization; go ahead and ignore any problems you can.
Maybe that branch will never be taken...  Ironically, this is also
largely school I, since it matches the if semantics.


Bad Case Option (5) -- ad hoc mixture
-------------------------------------

Pick an arbitrary set of rules, and follow it.

Guido is currently leaning towards this, with the rules being "freeze
at definition", raise for unhashable, ignore later changes, undecided
on overlapping ranges.

The disadvantage is that people can "cheat" with non-constant
expressions.  Sometimes, this will work out great.  Sometimes it will
lead to nasty non-localized bugs.  We have to explain exactly which
cheats are allowed, and that explanation could get byzantine.


Bad Case Option (6) -- Undefined
--------------------------------

Undefined behavior.  We don't yet know which strategy (or mix of
strategies) is best.  So don't lock ourselves (and Jython, and PyPy,
and IronPython, and ShedSkin, and ...) into the wrong strategy.

The down side is that people may start to count on the actual behavior
anyhow; then (in practice) we might just have Bad Case Option (5)
without documentation.

-jJ