[Python-Dev] Switch statement - handling errors

Jim Jewett jimjjewett at gmail.com
Tue Jun 27 21:21:46 CEST 2006

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

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.


More information about the Python-Dev mailing list