[Python-Dev] Switch statement - handling errors

[Guido van Rossum]

On 6/27/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> 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.

Thanks for the elaboration. I'm not sure how to respond except to
correct your representation of my position:

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

Actually I'm all for flagging overlapping changes as errors when the
dict is frozen.

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

Actually I would simply explain that all cheats are frowned upon, just
like all side effects in case expressions.

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


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